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This  thesis  provides  the  specifications  of  a  simulation 
model ,  based  on  a  given  functional  design  for  a  Local  Area 
Network  (LAN)  system,  which  implements  functions  of  the 
Stock  Point  Logistics  Integrated  Communication  Environment 
(SPLICE).  First,  today's  LAN  technologies  and  workload 
characterization  of  the  SPLICE  system  are  discussed  in 
general.  Then,  the  components  of  the  LAN  system  and  the 
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model  assumptions  are  identified  in  terms  of  an  open  network 
of  queues.  Finally,  an  initial  approach  for  model  implemen- 
tation  in  GPSS  is  provided. 
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I.  INTRODUCTION 


A.  GENERAL 

The  development  of  resource-sharing  network  can  facili¬ 
tate  the  provision  of  a  wide  range  of  economic  and  reliable 
computer  services.  Computer-communication  networks  allow 
the  sharing  of  specialized  computer  resources  such  as  data¬ 
bases.  programs,  and  hardware.  Such  a  network  consists  of 
both  the  computer  resources  and  a  communications  system 
interconnecting  them  and  allows  their  full  utilization  to  be 
achieved. 

Within  a  restricted  area  such  as  a  single  building,  or 
small  cluster  of  buildings,  high-speed  (greater  than 
1  Mbit/sec)  data  transmission  is  available  at  a  small 
fraction  of  the  cost  of  obtaining  comparable  long-haul 
service  from  a  tariffed  common  carrier.  Local  area  networks 
use  this  low-cost,  high-speed  transmission  capability  as  the 
basis  for  a  general-purpose  data  transfer  network.  As  the 
name  implies,  a  Local  Area  Network  (LAN)  is  a  data 
communication  network,  typically  a  packet  and  message 
communication  network,  limited  in  geographic  scope. 

As  a  result  of  the  growing  demands  for  automated  data 
processing  at  the  Navy  stock  points  and  inventory  control 
points,  long  range  plans  are  being  developed  around  the 
Stock  Point  Logistics  Integrated  Communication  Environment 
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(SPLICE)  concept.  Developers  of  SPLICE  have  decided  to 
employ  a  LAN  at  each  site  for  integration  of  all  computer 
resources.  The  future  integration  of  this  system  has  been 
considered  [Ref.  1].  That  is,  as  SPLICE  requirements  evolve 
and  as  technology  changes,  dissimilar  devices,  e.g.,  new 
host  computers,  mass  storage  devices,  teleprocessing  gate¬ 
ways,  can  be  added  to  the  LAN  without  having  to  redesign 
other  parts  of  the  SPLICE  system. 

There  are  two  major  objectives  behind  the  development  of 
SPLICE.  First,  there  is  the  increased  need  for  the  use  of 
CRT  display  terminals  to  interact  with  application  logic  and 
to  fetch  information  from  the  system  data  base.  Second, 
there  is  the  need  to  standardize  the  multitude  of  interfaces 
currently  existing  across  approximately  sixty  supply  sites 
[Ref.  1] . 

The  SPLICE  project  at  the  Naval  Postgraduate  School  will 
produce  specifications  and  recommendations  for  the  design  of 
the  LAN  to  be  implemented  at  stock  points  and  inventory 
control  points.  The  approach  taken  was  to  design  first  the 
logical  or  virtual  LAN,  specifying  all  the  functional 
modules,  their  characteristics  and  the  communication 
protocols,  rather  than  focusing  on  the  hardware  character¬ 
istics  first.  The  design  and  implementation  strategy  is 
based  on  a  distributed  architecture  for  LANs  [Ref.  1], 
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The  design  of  a  computer  communication  system  based  on  a 
functional  description  is  a  task  requiring  many  interrelated 
decisions  about  hardware  and  software.  The  decision  space 
for  such  a  problem  is  so  vast  that  it  cannot,  in  general,  be 
explored  completely.  Rather,  design  decisions  are  made 
sequentially,  and  the  resulting  system  structure  becomes 
progressively  more  constrained  at  each  step.  Use  of  dis¬ 
crete  simulation  can  be  a  powerful  tool  in  this  process  if 
its  role  is  carefully  planned. 

The  gross  behavior  of  the  proposed  system  can  be 
studied,  and  the  system  design  can  sometimes  be  changed  as  a 
result  of  such  study  before  these  changes  become  expensive. 
The  simulation  model  must  be  modified  at  each  step  of  the 
refinement  process  when  used  in  this  manner.  Care  is 
required,  however,  so  that  the  investment  in  simulation  at 
any  stage  does  not  outweigh  its  utility. 

Based  on  the  functional  specifications  provided  by 
Reference  1,  this  research  will  address  the  issue  of 
designing  an  efficient  simulation  model  in  order  to  be  used 
as  a  quantitative  tool  for  performance  evaluation  of  the 
particular  LAN  in  the  SPLICE  system. 


conceptualization  (specifications) ,  implementation,  and 
experimentation.  Towards  the  development  of  a  simulation 
model  for  the  LAN  implementing  the  SPLICE  functions,  this 
research  covers  the  conceptualization  and  part  of  the 
implementation  phase,  by  discussing  the  specifications  and 
providing  block  diagrams  for  such  a  model. 

2.  Acgigach 

The  application  of  simulation  to  many  types  of 
systems,  together  with  the  different  types  of  study  which 
may  be  involved,  result  in  many  variations  in  the  way  a 
simulation  study  proceeds.  Certain  basic  steps  in  the 
process  can,  however,  be  identified.  The  principal  steps 
are  considered  to  be  [Ref.  2]: 

-  Definition  of  the  problem 

-  Planning  the  study 

-  Formulation  of  the  model 

-  Construction  of  a  computer  program  for  the  model 

-  Validation  of  the  model 

-  Design  of  experiments 

-  Execution  of  simulation  run  and  analysis  of  the  results 

A  brief  discussion  of  each  step  taken  in  the 
development  process  follows: 

a.  Definition  of  the  problem:  Use  the  functional 
design  specifications  provided  by  Reference  1,  as  the  basis 
for  designing  a  simulation  model,  which  will  be  used  to 


estimate  the  performance  of  the  LAN,  in  terms  of  response 
and  transit  time,  in  order  to  result  in  the  best  LAN 
technology  and  hardware  configuration. 

b.  Planning  the  study:  (1)  A  general  study  of 
system  simulation  was  conducted  for  the  purpose  of  obtaining 
a  knowledge  of  system  simulation  and  selecting  an  appropri¬ 
ate  simulation  technique  to  be  used  with  the  LAN  simulation 
model.  (2)  Study  LAN  components  and  performance  measures  in 
general:  LAN  components  and  performance  measurements  were 
investigated  in  order  to  develop  a  knowledge  and  understand¬ 
ing  of  what  actually  composes  a  LAN  and  determine  the 
different  types  of  performance  measures  which  could  be  made 
on  computer  networks.  (3)  Data  analysis:  Data  provided  by 
Reference  3  have  been  analyzed  in  order  to  define  distribu¬ 
tions  and  other  parameter  values,  which  will  be  used  to 
drive  the  simulation  model.  (4)  Study  the  functional 
specifications  of  the  particular  LAN:  A  very  good  under¬ 
standing  of  the  particular  LAN  design  (functional  logic)  was 
necessary  in  order  for  the  model  to  be  suitable.  (5)  Study 
today's  LAN  technologies:  Today's  LAN  technologies  and 
their  performance  measurements  were  investigated  in  order  to 
develop  a  knowledge  of  their  advantages  and  disadvantages. 

(6)  Provide  specifications  for  a  particular  LAN  simulation 
model:  A  detailed  design  of  a  LAN  simulation  model  was 
provided  to  a  level  giving  a  valid  representation  of  the 
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system.  (7)  Study  the  GPSS  simulation  language:  This  final 
step  in  the  development  process  was  conducted  in  order  to  be 
able  to  draw  the  required  block  diagrams  of  the  simulation 
model. 

B.  OVERVIEW 

Following  the  steps  taken  in  the  development  process  of 
the  simulation  model,  this  thesis  discusses,  first,  in 
Chapter  II  today's  LAN  technologies.  Next,  in  Chapter  III, 
an  analysis  of  the  data  provided  by  Reference  3  was 
conducted  in  order  to  provide  workload  characterization. 
Then,  in  Chapter  IV,  the  specifications  of  a  simulation 
model  for  the  particular  LAN  are  given.  Finally,  Chapter  V 
is  concerned  with  the  implementation  of  the  simulation 
model . 


A.  GENERAL 


Designing  a  LAN  that  satisfies  user  demands  is  not  a 
simple  process.  It  requires  choosing  a  configuration,  a 
medium,  access  and  link -control  methods.  Additionally, 
decisions  have  to  be  made  about  where  to  position  the 
interface  and  which  industry  standards  to  observe.  Such  an 
approach  in  designing  a  LAN  is  shown  in  Reference  4. 

By  network  technology,  we  mean  the  mechanism,  both 
hardware  and  software,  by  which  various  computing  facilities 
are  interconnected  for  communication.  Potential  users  have 
to  select  the  appropriate  technology  for  their  intended 
applications  based  on  their  specific  performance  require¬ 
ments  and  operating  environment. 

It  is  necessary  to  go  through  a  brief  comparison  of  the 
most  popular  LAN  technologies  in  order  that  a  robust 
configuration  of  a  LAN  may  be  provided.  By  the  term  robust 
we  mean  "under  the  most  adverse  conditions,  specification 
requirements  are  met".  An  understanding  of  the  basic  prin¬ 
ciples  of  a  LAN  (such  as  those  contained  in  Reference  5) 
is  assumed. 


B.  LOOP  TOPOLOGIES 

Several  loop  topologies  for  LANs  have  been  proposed  in 
the  literature,  some  using  centralized  control,  others  using 
distributed  control.  The  loop  topology  concept  can  be 
augmented  with  additional  links  that  are  provided  from  each 
node  to  improve  performance  and  r eliability .  Any  node  or 
link  failure  disrupts  communication  unless  a  by-pass  is 
provided.  When  N  is  large  the  delays  may  be  excessive  and 
interface  overhead  increases  with  N  and  may  become  a  bottle¬ 
neck.  Multi-connected  loop  topologies  help  to  overcome 
these  problems.  For  higher  reliability  and  relatively  small 
maximum  distances  between  node  pairs,  regular  2-  and 
3-connect ed  loop  networks  can  be  constructed.  Such 
multi-connected  loop  technologies  can  sustain  several  node 
and  link  failures. 

The  number  of  nodes  directly  influences  the  message 
delays  in  loop  networks.  A  smaller  number  of  nodes  means 
the  messages  are  relayed  by  fewer  loop  interfaces,  and 
therefore  the  delays  will  be  less.  The  maximum  throughput 
under  saturated  conditions  and  the  reliability  of  loop 
networks  also  depend  on  loop  diameter,  which  is  related  to 
the  number  of  nodes.  Reference  6  shows  that  the  throughput 
performance  and  the  reliability  of  loop  networks  is  better 
when  diameters  are  small.  A  comparative  study  of  the 
various  multi-connected  loop  networks  proposed  in  the 
literature,  is  also  provided  by  Reference  6. 


C.  IEEE-802  TOKEN  RING 


A  token  ring  consists  of  a  set  of  stations  serially 
connected  by  a  transmission  medium.  Information  is 
transferred  sequentially,  bit  by  bit,  from  one  station  to 
the  next.  Each  station  regenerates  and  repeats  each  bit  and  “ 

v  -  * 

serves  as  the  means  for  attaching  one  or  more  devices 

(terminals,  work-stations)  to  the  network  for  the  purpose  of 

communicating  with  other  devices  on  the  network.  A  given  •< 

station  (the  one  that  has  access  to  the  medium)  transfers 

information  onto  the  ring,  where  the  information  circulates 

from  one  station  to  the  next.  The  addressed  destination 

station(s)  "copies"  the  information  as  it  passes.  As  can  be 

seen  from  Figure  2.1,  given  by  Reference  7,  the  physical 

connectivity  of  the  medium  establishes  the  logical  connec- 

tivity  of  active  stations  on  the  ring.  A  station  gains  the 

uV*V 

right  to  transmit  its  information  onto  the  medium  when  it 
detects  a  token  (free-token)  passing  on  the  medium.  The 

token  is  a  control  signal  comprised  of  a  unique  signalling  V-.l; 

sequence  that  circulates  on  the  medium  following  each  ..-Sr. 

e-  “ 

information  transfer.  Any  station,  upon  detection  of  a  ■ — J 

token,  may  claim  the  token  by  modifying  it  to  a  start-of- 
frame  sequence  (busy-token)  and  appending  appropriate 

address,  information,  frame  check  sequence  fields  and  the  •  4 

end-of-frame  delimiter. 


At  the  completion  of  its  information  transfer  and  after 
checking  to  ensure  that  the  proper  operation  has  resulted, 
the  station  initiates  a  new  token,  which  provides  other 
stations  the  opportunity  to  gain  access  to  the  ring.  A 
token-holding  timer,  started  at  the  beginning  of  information 
transfer,  controls  the  length  of  time  a  station  may  use  the 
medium  before  passing  the  token. 

The  token  ring  medium  access  method  specified  is  effic¬ 
ient  in  that  the  coordination  of  the  attached  stations 
requires  only  a  small  percentage  of  the  medium's  bandwidth 
capacity  when  the  offered  load  is  high,  as  stated  in 
Reference  7.  Each  station's  expected  access  delay  to  the 
medium  increases  no  faster  than  the  total  load  offered  under 
.overload  conditions. 

As  stated  in  Reference  7,  this  access  method  is  "fair" 
in  the  sense  that  it  provides  each  attached  station,  with  a 
given  class  of  services  (priority  level),  an  equal  share  of 
the  medium's  bandwidth  without  requiring  any  station  to  use 
its  full  share  at  any  particular  access  time.  Multiple 
levels  of  priority  are  available  for  independent  and  dynamic 
assignment  depending  upon  the  relative  class  of  service 
required  for  any  given  station,  e.g.,  synchronous  (real-time 
voice),  asynchronous  (interactive),  immediate  (network 
recovery) .  The  worst  case  bounds  for  any  station  to  gain 
access  to  the  medium  is  computable  in  the  absence  of  noise 
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and  with  due  consideration  given  to  the  priority  level 
interaction. 

Robust  detection  and  recovery  mechanisms  are  provided  to 
restore  network  operation  in  an  efficient  and  timely  manner 
in  the  event  that  transmission  errors  or  medium  transients 
(e.g.,  those  resulting  from  station  insertion  or  removal) 
cause  the  access  method  to  deviate  from  normal  operation. 
Detection  and  recovery  for  these  cases  utilize  a  network 
monitoring  function  that  may  be  distributed  in  all  stations 
or  optionally,  centralized  in  a  specific  station  with 
back-up  capability  in  one  or  more  alternate  stations. 

The  token  access  method,  as  specified,  does  not  place 
constraints  on  the  station  that  has  access  to  the  medium 
relative  to  the  logical  link  control  or  higher  level 
protocols  employed  to  effect  data  transfer.  This  access 
method  does  not  preclude  the  possible  use  of  other  data  link 
control  protocols,  e.g.,  ISO  HDLC  HRM,  X.2S  LAP-B,  ISO  basic 
mode ,  etc . 

D.  IEEE-802  TOKEN  BUS 

A  shared  medium  can  be  generally  categorized  into  two 
major  types  "BROADCAST"  and  "SEQUENTIAL".  On  a  broadcast 
medium,  each  node  will  receive  all  signals  transmitted  and 
media  of  this  type  are  most  often  associated  with  the  bus 
configuration.  On  a  sequential  type,  the  right  to  access 


the  medium  passes  from  node  to  node  in  a  logical  or  physical 
sense. 

In  IEEE-802  token  bus,  as  it  is  stated  in  Reference  7, 
the  token  medium  access  method  is  always  sequential  in  a 
logical  sense  as  depicted  in  Figure  2.2.  That  is,  during 
normal,  steady  state  operation,  the  right  to  access  the 
medium  passes  from  node  to  node  and  the  physical  connec¬ 
tivity  has  little  impact  on  the  order  of  the  logical  ring. 
Nodes  can  respond  to  a  query  from  the  token  holder  even 
without  being  part  of  the  logical  ring,  (e.g.,  in  Figure  2.2, 
nodes  H  and  F  can  respond  to  polls  and  receive  frames  but 
cannot  initiate  a  transmission  since  they  will  never  be  sent 
the  token) . 

The  token  (right  to  transmit)  is  passed  from  node  to 
node  in  numerically  descending  node  address  order.  After 
each  node  has  completed  transmitting  any  logical  link 
sublayer  ( LLC)  data  frames  it  may  have,  and  has  completed 
other  maintenance  functions,  the  node  passes  the  token  to 
its  successor  by  sending  a  "token"  frame. 

After  sending  the  token  frame,  the  node  listens  to  make 
sure  that  its  successor  hears  the  token  frame  and  is  active. 
If  the  sender  hears  a  valid  frame  following  the  token,  it 
assumes  that  its  successor  has  the  token  and  is  transmit¬ 
ting.  If  the  sender  does  not  hear  a  valid  frame  within  one 
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network  slot  time  it  assumes  the  successor  did  not  hear  the 
frame  and  resends  the  token. 

If  the  successor  does  not  respond  to  a  second  token 
frame,  the  sender  assumes  the  successor  has  failed.  The 
sender  now  sends  a  "who  follows"  frame  with  its  successor's 
address  in  the  data  field  of  the  frame.  All  nodes  compare 
the  value  of  the  data  field  of  a  "who  follows"  frame  with 
the  address  of  their  predecessor  (the  node  that  sends  them 
the  token).  The  node  whose  predecessor  is  the  successor 
(failed  node)  of  the  sending  node  responds  to  the  "who 
follows"  frame  by  sending  its  address.  The  node  holding  the 
token  establishes  a  new  successor,  bridging  the  failed  node 
from  the  logical  ring. 

If  the  sending  node  hears  no  response  to  a  "who  follows" 
frame,  it  repeats  the  frame  a  second  time.  If  there  is 
still  no  response,  the  node  tries  a  third  strategy  to 
re-establish  the  logical  ring.  The  node  now  sends  a 
"solicit  successor"  frame  asking  any  node  in  the  system  to 
respond  to  it.  If  there  are  any  operational  nodes  that  can 
hear  the  request,  they  respond  and  the  logical  ring  is 
re-established  using  the  response  window  process  to  add  new 
nodes  in  the  logical  ring  [Ref.  7] . 

If  two  attempts  at  soliciting  a  successor  fail,  the  node 
assumes  that  a  catastrophe  has  occurred.  Either  all  other 
nodes  have  failed,  the  medium  has  broken,  or  the  node's  own 
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receiver  has  failed  so  that  it  cannot  hear  other  nodes  who 
have  been  responding  to  its  requests.  In  this  case  the  node 
quits  attempting  to  maintain  the  logical  ring  and  simply 
listens  for  some  indication  of  activity  from  other  nodes. 

In  summary,  the  token  is  normally  passed  from  node  to  node 
using  a  short  token  pass  frame.  If  a  node  fails  to  pick  up 
the  token,  the  sending  node  uses  a  series  of  recovery 
procedures,  that  get  increasingly  drastic  as  the  node  fails 
to  find  a  successor  node. 

The  features  that  make  token-passing  different  from 
other  access  methods  are  as  described  in  Reference  7. 

1.  The  method  is  efficient  in  the  sense  that  the 
coordination  of  the  nodes  requires  only  a  small  percentage 
of  the  medium's  capacity  when  the  offered  load  is  high,  and 
that  each  node's  expected  access  delay  grows  no  faster  than 
the  total  offered  load  under  overload  conditions. 

2.  It  works  at  all  data  rates  and  distances  considered 
in  the  IEEE-802  functional  requirements,  and  has  the 
potential  for  growth  in  both  data  rate  and  distance. 

3.  The  method  is  fair  in  the  sense  that  is  offers  each 
node  an  equal  share  of  the  medium's  capacity,  without 
requiring  any  node  to  take  its  full  share. 

4.  It  permits  multiple  classes  of  service. 

5.  It  coordinates  the  node's  transmissions  so  that  they 
minimize  and  control  their  interference  with  each  other. 


6.  The  method  imposes  no  additional  requirements  on  the 
medium  and  the  modem  capabilities  over  those  necessary  for 
transmission  and  reception  of  multi-bit,  multi-frame 
sequences  at  the  specified  mean  bit  error  rate. 

7.  In  the  absence  of  system  noise,  the  method  provides 
computable,  deterministic,  worst-case  bounds  on  access  delay 
for  any  given  network  and  loading  configuration. 

8.  The  method  permits  the  presence  of  low-cost  reduced- 
function  nodes.  It  is  assumed  that  at  least  one  full- 
function  node  is  needed  to  make  the  system  operational.  An 
example  of  a  reduced  function  node  is  one  that  can  "receive 
only"  and  therefore  does  not  contain  access  control  logic. 

9.  Minimal  constraints  are  placed  on  how  a  node  which 
momentarily  controls  the  medium  may  use  its  share  of  the 
medium's  capacity.  In  particular,  the  access  method  does 
not  prohibit  any  node  from  using  other  specialized  access 
methods  (such  as  poll/ response )  during  that  node's  access 
period,  provided  only  that  those  specialized  methods  do  not 
confuse  the  other  nodes  on  the  network  as  to  the  state  of 
the  overall  access  mechanism. 

E.  PERFORMANCE  ANALYSIS 

1.  The  main  advantage  of  the  IEEE-802  technologies  is 
that  they  provide  standardization  in  the  following  sense: 
There  is  a  large  scale- separation  of  the  system  into  three 
parts,  the  Logical  Link  Control  (LLC)  sublayer,  the  Media 


Access  sublayer,  and  the  Thysical  Layer.  These  layers  are 
intended  to  correspond  closely  to  the  lowest  layers  of  the 
ISO  Model  for  Open  systems  interconnection.  The  LLC  and 
Media  Access  sublayers  together  encompass  the  functions 
intended  for  the  Data  Link  Layer  as  defined  in  the  OSI 
model.  Such  an  architectural  organization  has  two  main 
advantages: 

Clarity:  A  clean  overall  division  of  the  design  along 
architectural  lines  makes  the  standard  cleaner. 

Flexibility:  Segregation  of  medium-dependent  aspects  in 
the  Physical  Layer  allows  the  Logical  Link  Control  and 
Media  Access  sublayers  to  apply  to  a  family  of  trans¬ 
mission  media.  Partitioning  the  Data  Link  Layer  allows 
various  Media  Access  methods  within  a  single  family  of 
local  network  standards. 

2.  A  performance  comparison  made  by  Reference  8  through 
simulation  shows  the  following  results: 
a.  Contention  Bus 

The  mean  delay  time  remains  low  until  the  load 
is  close  to  the  maximum  channel  capacity.  The  contention 
time  to  gain  control  of  the  channel  is  independent  of  the 
packet  size  and  the  transmission  time  is  directly  propor¬ 
tional  to  the  packet  size.  Therefore,  the  absolute  delay 
per  packet  is  less  for  smaller  packets  while  the  average 
delay  per  bit  is  smaller  in  the  case  of  larger  packets. 

The  contention  time  increases  as  the  network 
load  increases  until  the  network  becomes  saturated. 
Therefore,  with  increasing  network  load,  the  present 
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increase  in  absolute  delay  is  higher  for  smaller  packets 


An  advantage  of  the  contention  bus  technology  is 
this:  for  a  given  load,  and  particularly  for  large  packet 
size,  the  mean  delay  time  is  not  very  sensitive  to  the 
number  of  active  stations  on  the  bus.  Even  with  only  four 
active  stations,  the  result  is  very  similar  to  that  of  128 
stations  [Ref.  8]. 

b.  Token  Ring 

Under  the  assumption  that  a  station  is  allowed 
to  put  all  waiting  packets  onto  the  ring  when  the  token 
arrives,  the  mean  absolute  delay  time  for  a  given  normal¬ 
ized  load  is  independent  of  the  packet  size.  Thus,  there  is 
no  need  to  talk  about  normalized  delay  time. 

It  has  been  shown  [Ref.  8]  that  as  the  number  of 
active  stations  increases,  the  delay  characteristics  get 
poorer.  For  example,  when  the  number  of  active  stations 
increases,  the  mean  delay  time  goes  up  by  approximately  a 
factor  of  2  at  all  load  levels.  This  is  because  an 
additional  station  adds  to  the  walk  time  delay  (i.e.,  the 
time  required  for  a  bit  to  go  once  around  the  idle  ring), 
thus  increasing  the  propagation  delay.  Contention  but 
technologies  do  not  suffer  from  this  disadvantage. 

c.  Slotted  Ring 

The  model  used  by  Reference  8  was  based  on  the 
assumption  that  the  packet  size  coincides  with  the  slot  size 
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and  that  the  gaps  between  slots  are  negligible,  for 
simplicity. 


If  we  keep  the  slot  size  constant  while  varying 
the  number  of  slots  n,  then  walk  time  increases  with  number 
of  slots.  This  explains  the  increase  in  absolute  delay  time 
as  n  increases  when  the  load  is  light.  However,  for  a  given 
load,  the  probability  of  finding  an  empty  slot  increases  as 
n  is  increased.  At  higher  loads,  this  wait  time  dominates 
the  delay  time  and  the  mean  delay  time  actually  decreases  as 
n  goes  up.  More  load  can  be  accommodated  before  the  system 
saturates,  as  well. 

If  we  keep  the  walk  time  constant,  varying  the 
number  of  slots,  then  the  slot  size  decreases  as  n 
increases.  The  normalized  delay  is  shorter  for  larger  slot 
(and  thus  packet)  sizes. 

It  has  been  shown  [Ref.  8]  that  for  a  given  slot 
size  and  number  of  slots  in  the  ring,  there  is  a  optimal 
number  of  active  stations  N  which  minimizes  the  mean  delay 
time  and  maximizes  the  saturation  load.  For  a  given  load, 
the  larger  the  value  of  N,  the  smaller  the  mean  number  of 
packets  waiting  at  each  station.  Thus  the  mean  queue  wait 
time  monotonically  decreases  as  N  increases.  However, 
because  the  number  of  stations  ready  to  transmit  has 
increased,  the  mean  wait  time  to  acquire  an  empty  slot 
monotonically  increases.  Furthermore,  the  walk  time 
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increases  monotonically  with  N.  The  opposing  effects  on  the 
mean  delay  time  as  N  varies  imply  that  there  is  a  value  of  N 
which  minimizes  the  mean  delay  time  for  a  given  load.  It 
has  been  shown  [Ref.  8]  that  this  value  remains  constant  for 
all  load  levels.  Knowledge  of  this  information  allows  us  to 
estimate  how  close  an  existing  ring  is  operating  from  its 
theoritical  optimum.  It  also  allows  an  estimate  of  how  many 
stations  should  be  attached  to  the  ring. 

d.  Reliability 

The  basic  ring  topology  has  often  been  criti¬ 
cized  as  being  unreliable  on  the  grounds  that  an  open 
circuit  anywhere  or  the  failure  of  any  repeater  will  disrupt 
the  entire  network.  This  is  certainly  a  problem  with  a 
large  number  of  repeaters  strung  together.  However,  the 
"star-shaped  ring"  design  with  a  wire  center  at  the  hub  of  a 
star-configured  network  has  greatly  alleviated  the  problem. 

The  contention  bus  is  essentially  a  passive 
device,  thus  its  reliability  is  much  higher  than  that  of  the 
basic  ring  design.  However,  with  the  use  of  repeaters  in 
more  complex  bus  systems,  the  reliability  decreases. 

e.  Fairness 

Due  to  the  nature  of  the  two  technologies,  the 
ring  seems  superior  to  the  contention  bus  technology.  Due 
to  the  back-off  formula  used  for  contention  busses,  the 
collided  packets  are  discriminated  against  in  favor  of  the 


freshly  arrived  ones.  Thus  a  packet  that  has  just  arrived 
has  a  higher  probability  of  getting  to  its  destination 
before  a  packet  that  may  arrive  earlier  and  which  has 
suffered  one  or  more  collisions. 

f.  Maintainability  -  Extensibility 

Both  have  been  improved  in  ring  technologies  and 
are  comparable  to  the  passive  bus. 

g.  Summary  of  Performance  Comparison 

In  general,  the  CSMA/CD  bus  technology  should 
have  lower  mean  delay  time  than  the  ring  technologies  when 
the  load  is  light  (probability  of  collision  small) .  This  is 
because,  unlike  the  ring  technologies  where  a  station  must 
wait  for  the  arrival  of  the  token  or  an  empty  slot,  a 
station  can  transmit  the  packet  at  once.  It  is  interesting 
to  note  that  the  acknowledgement  of  the  arrival  of  a  packet 
in  the  ring  technologies  is  essentially  the  original  packet 
itself.  Thus  the  packet  cannot  be  removed  from  the  channel 
until  it  has  completed  at  least  one  round  trip.  If  the 
packet  is  very  large,  then  we  waste  channel  bandwidth. 

Broadcast  contention  bus  technology  suffers  from 
the  fact  that  the  upper  bound  of  delay  time  is  non-determin- 
istic.  Thus  it  is  not  appropriate  for  real  time  applica¬ 
tions.  Furthermore,  the  theoretical  maximum  network  length 
is  generally  shorter  than  the  ring  technologies  (e.g.,  it  is 
500  meters  per  line,  2.5  km  between  any  two  stations  in  a 
hierarchial  network  for  Ethernet) . 


As  a  result  of  the  previous  discussion,  we 

\ 

believe  that  the  best  way  to  select  the  appropriate  tech¬ 
nology  for  the  SPLICE  LAN,  is  the  development  of  a  simula¬ 
tion  model,  based  on  the  functional  specifications  of  the 
SPLICE  LAN.  Such  a  model  will  provide  a  performance 
evaluation  for  different  technologies  in  accordance  with  the 
SPLICE  requirements. 


A.  GENERAL 


It  is  crucial  to  the  performance  evaluation  of  the 
SPLICE  LAN,  that  an  accurate  characterization  and  projection 
be  made  of  the  Automated  Data  Processing  (ADP)  workload  to 
be  supported  by  the  system  through  the  1980's  and  early 
1990's. 

The  SPLICE  system  is  designed  to  provide  a 
telecommunications  "Front  End"  to  the  existing  Stock  Point 
computer  complexes  and  to  support  the  implementation  of 
interactive  transaction  processing.  The  processing  of  batch 
applications  on  the  SPLICE  configuration  is  to  be  held  to  a 
minimum,  since  the  existing  Stock  Point  computer  complex  is 
to  continue  to  provide  batch  processing  support.  Thus  the 
workload  of  most  interest  are  interactive  transactions 
(whether  for  processing  within  a  SPLICE  complex  or  for 
forwarding  to  a  remote  Stock  Point  computer  complex)  . 

B.  BACKGROUND 

Reference  3  defines  the  SPLICE  configuration  require¬ 
ments  by  projecting: 

-  the  arrival  of  units  of  work  at  SPLICE  processing 
facilities  (workload  analysis) . 

-  the  amount  of  processing  resources  comsumed  in  the 
satisfaction  of  the  workload  demand  (process  load) . 
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-  the  magnitude  of  system  resources  available  in  each 

configuration  (configuration  sizing). 

Before  we  go  any  further,  it  was  felt  that  some 
definitions  have  to  be  provided  for  better  understanding. 

MESSAGE:  A  single  transmission  of  a  user's  data 
between  two  points. 

TRANSACTION:  A  series  of  MESSAGES,  in  one  or  both 
directions,  which  together  achieve  a  unit  of  work,  as 
defined  by  the  particular  application. 

WORKLOAD:  The  arrival  of  TRANSACTIONS  for  processing 
at  the  SPLICE  complex. 

PROCESS  LOAD:  The  individual  demand  for  ADP  system 
service  (by  component)  caused  by  the  arrival  of  a 
TRANSACTION. 

COMPONENT:  A  segment  of  the  PROCESS  LOAD  (i.e.,  edit, 
validation,  etc.). 

The  eight  major  components  of  a  transaction  life  cycle 
are  provided  below  and  a  simplified  transaction  processing 
algorithm  is  depicted  in  Figure  3.1. 

-  Input/Edit:  The  editing  of  the  input  MESSAGE  without 

reference  to  files. 

-  Validation  Read:  The  acquisition  of  records  for  further 

MESSAGE  validation. 

-  Validation:  The  final  checking  of  the  MESSAGE  against 

the  records. 

-  Error  Messages:  The  output  if  any  of  the  previous  steps 

fail. 

-  Process  Read:  The  acquisition  of  records  for 

processing. 

-  Process:  The  actual  information  transformation/process. 

-  File  Write:  The  modification/addition  of  records. 


. . .  • 
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-  Output.*  The  generation  of  a  MESSAGE  in  response  to  the 
input . 

Definitions  for  each  of  the  parameters  involved  in  the 
above  eight  major  components  are  as  follows: 

Transaction  Class:  A  numeric  transaction  class 
identifier. 

Input  Message  Length:  The  average  length  of  an  input 
message  in  characters  including  all  protocol  and/or  control 
characters. 

Input  Edit  Instructions:  The  number  of  instructions 
executed  to  edit  the  input  message  without  or  before 
accessing  secondary  storage  files. 

Input  Edit  Failure:  The  percentage  of  input  messages 
that  fail  to  pass  the  preliminary  input  edits. 

Validation  Reads:  The  number  of  records  read  for  the 
purposes  of  validating  the  input  message. 

Validation  Read  Instructions:  The  number  of 
instructions  necessary  to  prepare  for  and  execute  a  read 
operation. 

Validation  Record  Length:  The  average  number  of 
characters  read  per  validation  record  including  any  overhead 
characters. 

Validation  Read  Failures:  The  percentage  of  messages 
for  which  the  validation  read  operation  fails. 

Validation  Instructions:  The  number  of  instructions 
executed  in  the  process  of  final  input  message/transaction 
validation. 

Validation  Failures:  The  percentage  of  messages  for 
which  the  validation  process  fails. 

Error  Message  Format  Instructions:  The  number  of 
instructions  executed  to  format  and  write  back  to  the 
terminal  an  error  message  following  a  validation  failure. 

The  proaessing  of  the  message  is  assumed  to  continue  with 
the  input  of  the  revised  message. 


Error  Message  Length:  The  number  of  characters  in  the 
error  message  including  any  formal  and/or  control 
characters . 

Processing  Reads:  The  number  of  records  read  in 
anticipation  of  processing  (in  addition  to  the  records  read 
for  validation) . 

Processing  Read  Record  Length:  The  average  number  of 
characters  in  the  records  read  for  processing. 

Processing  Read  Instructions:  The  number  of 
instructions  executed  to  prepare  for  an  to  execute  the 
reading  of  records  for  processing. 

Processing:  The  number  of  instructions  executed  during 
the  processing  phase  of  the  transaction. 

File  Modifies:  The  number  of  records  written  to  files 
that  do  not  require  any  structural  maintenance  to  index  or 
directory  files. 

Modified  Record  Length:  The  average  number  of 
characters  written  during  modify  operations. 

File  Adds:  The  number  of  records  written  which  require 
structural  maintenance  to  all  associated  index  or  directory 
files. 

Added  Record  Length:  The  average  number  of  characters 
written  during  add  operations. 

Modify/Add  Instructions:  The  number  of  instructions 
executed  to  prepare  for  an  to  execute  the  modification/ add 
of  records. 

Output  Format  Instructions:  The  average  number  of 
instructions  executed  to  format  the  output  message. 

Output  Message  Length:  The  average  number  of  characters 
in  the  output  message  including  any  format  and/or  control 
characters. 

Output  Records:  The  lumber  of  output  messages  written. 


C.  WORKLOAD  FORECAST 

The  workload  forecast  has  been  prepared  in  Reference  3 
for  each  of  the  21  SPLICE  main  processing  complexes  and  the 
process  load  is  described  in  terms  of  twelve  transaction 
archetypes  which  will  not  change  over  the  life  of  the  SPLICE 
contract.  Instead  of  determining  the  resource  requirements 
for  each  individual  transaction,  the  above  set  of  twelve 
transaction  classes  has  been  defined. 

The  workload  characteristics  of  the  most  representative 
site  (NSC  NORFOLK)  are  provided  in  Appendices  A  and  B,  which 
will  be  discussed  in  this  chapter. 

The  way  data  were  provided  by  Reference  3  did  not  help 
much  for  obtaining  an  accurate  characterization  of  the 
transaction  arrivals  in  the  LAN  system,  but  since  these  were 
the  only  data  available,  they  are  utilized  to  the  extent 
possible. 

We  analyzed  the  given  data  in  many  ways  in  order  to 
reach  the  most  reasonable  conclusions  about  the  distribu¬ 
tions  and  the  frequencies  that  characterize  the  transaction 
arrivals  into  the  LAN  system. 

First,  the  maximum  peak  rate  of  transactions  per  six 
month  period  is  considered  to  be  an  insufficient  amount  of 
data  for  defining  distributions  of  arrivals  in  a  computing 
system.  Thus,  lacking  definitive  information,  we  assume 
uniformly  distributed  transaction  arrivals  within  each  six 
month  period  in  order  to  cover  the  peak  rates. 
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Applying  the  goodness  of  fit  test  on  data  per  each  of 
the  twelve  transaction  classes  over  the  total  period  (1982- 
1993) ,  we  found  that  the  data  are  uniformly  distributed  with 
an  exponential  growth  over  time  (Appendices  E  through  P) . 
This  result  seemed  highly  unlikely;  therefore,  the  data  in 
Reference  3  are  suspect. 

Examining  the  data  independently  of  transaction  classes 
over  the  total  period  (1982-1993)  and  applying  the  goodness 
of  fit  test,  we  found  that  the  distribution  was  very  close 
to  a  logarithmic  one  as  it  is  shown  in  Appendix  C.  It  is 
known  though  that  logarithmic  distributions  are  not 
representative  of  arrival  data  for  computer  systems.  Thus, 
we  could  not  support  such  a  conclusion  for  that  particular 
site  (NSC  Norfolk) . 

Since  our  analysis  casts  doubts  on  the  validity  of  the 
forecast  data  in  Reference  3  and,  in  addition,  a  subsequent 
study  [Ref.  9],  refuted  these  data,  and  lacking  real  data 
(SPLICE  has  not  been  implemented),  we  concluded  that  the 
most  reasonable  assumption  about  transaction  arrival  rate  is 
that  it  is  Poisson. 

In  order  to  estimate  the  frequency  of  occurrence  of 
transaction  classes,  we  calculated  horizontally  the  per¬ 
centage  of  each  transaction  class  per  six  month  period  and 
then  we  computed  the  overall  percentages  per  transaction 
class  in  order  to  check  consistency  of  the  results.  That 
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was  necessary  in  order  to  define  the  frequency  of  occurence 
for  each  particular  transaction  class  to  be  used  later  in 
the  model  for  transaction  class  selectimn.  Results  of  the 
above  computations  are  given  in  Appendix  D. 

Results  for  the  goodness  of  fit  tests  (X^)  fo?  dis¬ 
tributions  per  transaction  class  over  the  total  period 
are  shown  in  Appendices  E  through  P. 

D.  OVERVIEW 

In  general,  there  is  a  feeling  that  the  data  provided  by 
Reference  3  are  not  valid:  (wrong  summations  for  the  total 
volume  of  transactions  per  six  month  period,  data  for  every 
transaction  class  are  uniformly  distributed  over  the  ten 
year  period,  logarithmic  distribution  is  not  generally 
acceptable  for  real  data,  etc.).  Since  there  are  no  other 
data  available,  we  used  the  frequency  table  in  Appendix  D  as 
the  best  approximation  available  at  the  moment. 
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IV.  SPECIFICATIONS  OF  THE  LAN  SIMULATION  MODEL 

A.  INTRODUCTION 

A  definition  given  by  Reference  10  describes  a  simula¬ 
tion  model  as  "a  logical-mathematical  representation  of  a 
concept,  system,  or  operation  programmed  for  solution  on  a 
high-speed  electronic  computer."  A  more  general  one  given 
by  Reference  11  defines  a  simulation  as  the  answer  to  the 
question  "What  if  ...?". 

A  simulation  model  can  be  constructed  and  applied  during 
any  phase  of  system  design  or  predesign  conceptualization. 

It  depends  upon  the  answers  desired  about  the  system  as  to 
when  a  model  should  be  constructed.  According  to  Reference 
10,  a  simulation  can  be  constructed: 

1.  Before  the  system  is  desiqned  in  order  to  determine 
parameter  sensitivity  and  to  optimize  or  evaluate 
the  system  design. 

2.  During  the  system  design  phase,  in  order  to  test  and 
experiment  with  system  design  concepts. 

3.  After  a  system  has  been  designed  and  built  in  order 
to  supplement  system  test  results  and  to  evaluate 
overall  system  effectiveness. 

In  simulation  of  a  computer  facility,  a  critical  issue 
is  the  level  of  detail  at  which  the  simulation  is  to 
operate.  Reference  12  distinguishes  two  extreme  levels  of 
detail;  in  practice  of  course,  there  exists  between  the  two 
extremes  a  whole  spectrum  of  levels.  We  will  call  the 
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extremely  fine  level  of  detail  the  "micro  level"  and  the 
extremely  aggregated  level  the  "macro  level". 

At  the  micro  level,  the  effects  of  each  individual 
machine-language  instruction  are  simulated.  The  trans¬ 
actions  are  machine-language  instructions  and,  perhaps, 
input-data  sets.  The  state  of  the  system  includes  the 
contents  of  main  memory,  auxilliary  storage,  and  other 
output-data  sets.  The  processor  and  the  channels  are 
treated  as  servicing  entities.  Thus,  micro-level  simula¬ 
tions  are  expensive  both  in  terms  of  programming  time  and  in 
terras  of  running  time.  Furthermore,  simulation  at  the 
micro-level  requires  an  extremely  detailed  understanding  of 
the  functions  of  the  operating  system,  because  these  details 
must  be  incorporated  into  the  logic  of  the  model.  Micro¬ 
level  simulations  are  useful  for  study  of  computer-design 
problems.  They  can  give  the  designer  insight  into  the 
consequences  of  modifying  the  instruction  set  or  the 
hardware  and  software  capabilities.  However,  in  a  simula¬ 
tion  intended  to  determine  how  to  process  a  user's  workload, 
this  level  of  detail  seems  to  be  unnecessary  and  probably 
undesirable. 

At  the  macro  level,  the  effects  of  processing  complete 
jobs  are  simulated,  with  each  transaction  representing  a 
total  job.  The  state  of  memory  is  described,  not  in  terms 
of  its  contents,  but  rather  in  terms  of  the  number  of 
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storage  locations  that  are  busy  or  idle.  This  is  the  level 
most  often  used  in  simulation  of  computer  systems  in  order 
to  evaluate  a  system's  performance  more  effectively. 

This  thesis,  as  part  of  the  SPLICE  project  at  the  Naval 
Postgraduate  School,  intends  to  support  the  functional 
desiqn  of  a  LAN  implementing  the  SPLICE  functions,  by 
discussing  in  this  chapter  the  specifications  of  a  macro 
level  simulation  model  which  will  help  in  the  LAN  design, 
optimization  and  evaluation, 
l.  Background 

Today's  computer  systems  have  evolved  a  great  deal. 
They  are  now  many  devices  capable  of  independent  operation; 
jobs  can  follow  complex  routing  paths,  returning  to  any 
device  many  times;  different  kinds  of  jobs  can  place  differ¬ 
ent  demands  on  different  devices.  New  system  features 
include  concurrent  programs,  multiprogramming,  multiproces¬ 
sing,  distributed  processing,  timesharing  and  virtual 
memory.  It  is  no  longer  obvious  how  to  use  a  job's  input, 
execution,  and  output  time  to  compute  throughputs  and 
response  times  in  the  system,  or  how  to  evaluate  a  computer 
system's  performance. 

Queueing  network  models  have  proved  to  be  cost 
effective  tools  for  analyzing  modern  computer  systems.  The 
increasing  popularity  of  queueing  network  models  for 
computer  systems  has  three  bases  according  to  Reference  13: 
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a.  These  models  capture  the  most  important  features 


of  actual  systems,  e.g.,  many  independent  devices  with 
queues  and  jobs  moving  from  one  device  to  the  next.  Experi¬ 
ence  shows  that  performance  measures  are  much  more  sensitive 
to  parameters  such  as  mean  service  time  per  job  at  a  device, 
or  mean  number  of  visits  per  job  to  a  device,  than  to  many 
of  the  details  of  policies  and  mechanisms  throughout  the 
operating  system  (which  are  difficult  to  represent 
concisely) . 

b.  General  service  time  distributions  can  be 
handled  at  many  devices;  load-dependent  devices  can  be 
modeled;  multiply  classes  of  jobs  can  be  accommodated. 

c.  The  algorithms  that  solve  the  equations  of  the 
model  are  available  as  highly  efficient  queuing  network 
evaluation  packages. 

The  use  of  discrete  simulation,  employing  a  queueing 
network  model,  can  be  a  powerful  tool  in  the  process  of 
modeling  the  SPLICE  LAN  if  its  role  is  carefully  planned. 

2.  Overview 

In  our  case  we  will  describe  a  LAN  simulation  model, 
based  on  the  functional  specifications  provided  by 
Reference  1,  as  an  open  queueing  network.  First,  the 
simulation  model  resources  will  be  described  in  terms  of  the 
components  which  compose  the  model  LAN,  i.e.,  the  functional 
modules  described  in  Reference  1,  processing  unit,  memory 


unit  and  disc  unit.  Next,  how  these  components  are  modeled 
as  an  open  queueing  network  is  defined  assuming  an  on-line 
environment  with  different  classes  of  transactions. 

Finally,  the  transaction  flow  through  the  LAN  simulation 
model  and  the  selection  of  transaction  classes  are  described 
in  terms  of  the  stochastic  processes  representing  the  flow 
through  the  queueing  network. 


B.  SIMULATION  MODEL  COMPONENTS 

The  simulation  model  resources  are  described  below  in 
terms  of  components  which  compose  the  LAN  model.  For  this 
particular  desiqn  the  resources  which  serve  user 
transactions  and  contribute  to  delay,  according  to 
Reference  1,  are  the  following: 

1.  Local  Communication  Module  (LC) 

-  Bus  arbitration,  i.e.,  traffic  management. 

-  Message  transmission  and  reception  including 
buffer  management. 

-  Message  control  (e.g.,  error  detection,  correction 
and  acknowledgement)  . 

-  Administration  (message  accounting,  lost  or 

-  Misdirected  message  handling,  LAN  recovery  and 
shutdown)  . 

2.  National  Communication  Module  (NC) 

-  Conversion  of  Defense  Data  Network  protocol  to 
LAN  protocol  and  vise  versa. 

-  Message  assembly/disassembly. 

3.  Front-End  Processing  (FEP) 

-  Terminal  and  communication  line  buffering. 

-  Code  conversion. 

-  Byte/word  assembly/disassembly. 

4.  Terminal  Management  (TM) 

-  Message  editing. 

-  Screen  management. 

-  Virtual  terminal  operations. 


5.  Data  Base  Management  (DBM) 

-  File  creation. 

-  File  update. 

-  Query  processing  and  data  retrieval. 

-  Data  dictionary  creation  and  maintenance. 

-  File  catalog  creation  and  maintenance. 

6.  Session  Services  (SS) 

-  Establish  and  maintain  local  and  remote  sessions: 

*  within  the  LAN. 

*  with  local  host(s). 

*  with  remote  host(s). 

-  Provide  logical  and  physical  network  addresses 
based  on  value  of  services  request  code. 

7.  Peripheral  Management  (PM) 

-  Management  of  unit  record  input/output 

*  read  a  card. 

*  print  a  line,  etc. 

*  spool  files  for  input  and  output. 

-  Optical  Character  Recognition  or  Mark  Sense 
Equipment. 

8.  Resources  Allocation  (RA) 

-  Allocation  of  shared  resources  to  functional 
modules. 

*  Record  keeping  concerning  allocation  of  shared 
resources. 

*  Locating,  accessing  and  making  shared 
resources  (e.g.,  memory,  disk)  available  to 
functional  modules. 

In  addition  to  the  above  model  LAN  components,  which  are 
considered  as  individual  user  transaction  servers  in  the 
queueing  network,  the  following  physical  resources  will  also 
be  considered  as  model  components  representing  individual 
servers,  but  instead  of  servicing  user  transactions,  they 
will  service  functional  modules  (they  will  be  servers  of 
servers)  . 
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9.  Processing  units. 

10.  Disk  storage. 

11.  Memory  storage. 

Industry  standards  for  seek  time,  rotational  delay  time 
and  transfer  time  will  be  used  to  estimate  the  mean  service 
time  per  functional  module  for  each  transaction  class. 

C.  MODEL  ASSUMPTIONS 

1.  The  One-Line.  One-Server  Queueing  system  is  assumed 
for  each  particular  server  in  the  system. 

2.  Since  data  provided  by  Reference  3  do  not  fit  any 
theoretical  distribution  at  an  acceptable  level  of  signif¬ 
icance.  it  is  assumed  that  the  transaction  arrivals  are 
random,  characterized  by  a  Poisson  distribution  with  mean 
inter arrival  time  equal  to  the  reciprocal  of  the  total  peak 
rate  per  six  month  period,  given  in  Appendix  A. 

3.  The  interarrival-time  random  variable  is  assumed  to 
be  exponentially  distributed  and  integer  valued. 

4.  Like  interarrival  time,  service  time  for  each  par¬ 
ticular  class  of  transactions  per  functional  module  (server) 
is  assumed  to  be  exponentially  distributed  and  integer 
valued.  The  mean  service  time  in  our  case  will  be  computed 
based  on  current  industry  standards. 

5.  A  random-number  generator  is  assumed  to  be  avail¬ 
able.  A  description  of  such  a  generator  will  be  given  later 
in  this  chapter. 
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6.  It  will  be  assumed  that  all  arriving  transactions 
will  remain  for  service  up  to  a  maximum  quantum  of  time 
defined  by  an  operating  system's  timer. 

7.  When  the  simulation  begins,  the  system  will  be 
assumed  to  be  "empty  and  idle".  That  is.  there  are  no 
transactions  in  the  queue  initially,  and  the  servers  are 
idle. 

8.  After  the  simulation  has  been  started,  it  should 
continue  until  a  length  of  simulated  time,  which  is  provided 
as  a  parameter,  has  elapsed.  In  general,  then,  when  the 
simulation  is  stopped,  the  servers  may  be  in  the  process  of 
providing  service,  and  there  may  be  one  or  more  transactions 
in  the  queue . 

9.  A  priority  scheme  for  each  server  in  the  system 
(functional  module  or  physical  resource)  will  be  applied, 
defining  the  following  levels  of  priority  among  the 
transactions  (from  highest  to  lowest) . 

a.  Control  Output  from  FM. 

b.  Control  Input  to  a  FM. 

c.  Control  Processing  for  a  FM. 

d.  Data  Output  from  FM. 

e.  Data  Input  to  a  FM. 

f.  Data  Processing  for  a  FM. 


10.  The  processing  sequence  per  transaction  class 
through  the  functional  modules  is  assumed  to  be  given.  Such 
a  sequence  can  be  determined  by  mapping  the  process  load 
components  to  subcomponents  of  the  functional  modules. 

11.  As  the  simulation  proceeds,  information  on  the 
maximum  queue  lengths  per  server  should  be  recorded.  Enter 
and  exit  times  per  transaction  should  be  recorded  also,  in 
order  to  compute  the  delay  time.  Interarrival  time  and 
service  time  distributions  in  effect  and  total  simulation 
time  should  also  be  recorded. 

D.  RANDOM  NUMBER  GENERATOR 

When  a  Poisson  arrival  process  is  to  be  simulated,  it  is 
not  the  arrival  rate  which  is  of  direct  interest;  instead, 
it  is  the  corresponding  interar rival  times  which  must  be 
known.  This  is  consistent  with  computing  the  time  of  the 
next  transaction's  arrival  by  adding  to  a  copy  of  the 
clock's  current  reading  a  value  drawn  from  an  interarrival¬ 
time  distribution.  When  arrival  rates  are  Poisson  distri¬ 
buted,  then,  the  corresponding  interarrival  times  are 
exponentially  distributed. 

Given  a  value  drawn  from  a  0-1  uniform  random  number 
generator  described  in  Reference  14,  the  corresponding 
inter arrival  time  can  be  directly  computed  by  the  following 
equations 
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IATsample  ~  ^IATavg^”^oge^_RNj^ 


where  IATsampie  stands  for  the  sampled  interarrival  time 

value;  IAT  is  the  average  interarrival  time  in  effect; 
dv  y 

RNj  is  a  uniformly  distributed  random  number  between  01 , 


and  -\J loge  represents  the  natural  logarithm  operation.  To 
draw  a  sample  from  the  exponential  distribution  whose 
average  value  is  IAT^^,  then,  the  sequence  indicated  by 
the  above  equation  has  to  be  followed: 

a.  Draw  a  value  from  a  0-1.  uniform  distribution. 

b.  Compute  the  natural  log  of  1  minus  the  random 
number. 

c.  Multiply  the  negative  of  this  natural  logarithm  by 
IAT 

avg* 

Recalling  that  the  values  of  RNj  range  over  the 

closed  interval  from  .000000  to  .999999,  we  note  that 

1°9„(1-RN-)  is  either  0  (for  an  RNS  value  of  .000000)  . 

or  negative  (for  RNj  values  greater  than  .000000).  The 

quantity  -log  (1-RN^)  is  consequently  non-negative;  and, 

“  J 

because  IAT  must  be  non-negative  as  well,  the  value  of 

av  y 

IAT^^p^  computed  from  the  equation  given  above  is  also 
non-negati ve. 


E.  TRANSACTION  E|L0W 

A  transaction  flow  through  the  LAN  system  simulation 


model  is  a  flow  through  the  network  of  queues,  each  modeling 
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: 


one  functional  module.  The  queueing  network  which  repre¬ 
sents  the  LAN  system,  as  it  was  discussed  earlier,  is  not 
considered  and  modeled  as  a  whole#  but  it  is  decomposed  into 
modules  which  are  analyzed  in  isolation.  The  focus  in  this 
approach  is  on  stochastic  processes  representing  the  flow 
through  each  module  where  the  output  of  one  module 
represents  the  input  to  a  subsequent  module. 

The  flow  in  the  simulation  model  can  be  portrayed  as  a 
series  of  discrete  events  as  it  is  shown  in  Figure  4.1  for 
transaction  class-1.  The  occurence  or  timing  of  these 
events  is  on  a  next  event  scheduled  basis;  details  will  be 
discussed  later  in  the  implementation  phase.  Also,  the 
occurence  of  the  events  is  governed  by  the  various  statis¬ 
tical  distributions  of  the  requirements  which  are  placed  on 
individual  system  modules  and  physical  resources, 
l-  Transact  ion-Clas.s_Select  ion 

The  selection  and  processing  of  a  transaction 
involves  the  determination  of  its  class  and  consequently  the 
module  visitation  sequence#  the  amount  of  physical  resources 
required,  and  the  mean  service  time  per  module  for  this 
particular  transaction  class.  The  visitation  sequence  can 
be  defined  by  mapping  the  process  load  demands  to  the 
subcomponents  of  the  functional  modules.  The  physical 
resources  required  and  the  mean  service  time  can  be 
estimated  according  to  the  current  industry  standards. 


*  •  * 


RESOURCES 

Disk,  Memory,  Processor  Units 
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The  arrival  of  transactions  at  their  initial  input 
into  the  Front-End  processor  has  been  characterized  by  a 
Poisson  process,  assuming  independent  and  random  inputs. 

Then  it  can  be  shown  [Ref.  15]  that  the  transaction  inter¬ 
arrival  times  are  exponentially  distributed  over  a  mean 
interarrival  time.  The  latter  can  be  computed  through  the 
total  peak  rate  of  transactions  for  each  six  month  period, 
by  taking  the  reciprocal  of  this  peak  rate.  For  example,  in 
Appendix  A  the  total  volume  for  the  first  six-month  period 
for  transaction  class-1  is  27  .52411  transactions  per  second, 
then,  the  mean  interarrival  time  is  1/27.52411  =  .036332 
seconds.  Using  a  random  number  generator,  we  will  take  a 
sample  value  from  the  exponentially  distributed  interarrival 
times,  which  is  the  interarrival  time  for  the  next  arrival. 
This  sample  value  will  be  added  to  the  copy  of  the  simula¬ 
tion  clock  in  order  to  determine  the  time  of  the  next 
arrival . 

The  class  of  the  transaction  input  to  the  system  is 
determined  by  referring  to  cummulative  probability  of 
occurrance  (Table  IV-I)  according  to  the  frequency  of 
occurrance  per  transaction  class,  given  in  Appendix  D.  A 
uniform  random  number  generator  is  used  drawing  a  sample 
value  between  .0000  and  .9999  in  order  to  define  the 
probability  and  then  the  transaction  class. 


TRANSACTION  CLASS  SELECTION  (FIRST  SIX-MONTH  PERIOD  1982.0) 


NOTE:  Disk  and  Memory  units  are  in  Kbytes,  processing  capacity  is  expressed  in 

FLOP'S  (floating  point  operations  per  unit  of  time).  Numbers  in  the  visitation 
sequence  column  are  taken  from  Table  V-I  and  they  represent  the  corresponding 
modules  to  be  visited  in  the  indicated  sequences. 


After  a  transaction  has  been  assigned  a  class,  the 
module  visitation  sequence  and  the  amount  of  the  required 
physical  resources  are  determined.  The  availability  of 
physical  resources,  then,  is  tested  one  by  one  and  the 
transaction  processing  begins. 

An  additional  random  number  generator  is  used  in 
order  to  obtain  sample  values  for  service  time  for  each 
module  per  transaction  class,  based  on  the  given  mean 
service  time. 

Various  statistics  associated  with  the  transaction 
and  the  LAN  system  model  are  accumulated  and  updated  and  the 
transaction  exits  the  model. 

Congestion  points  can  be  identified  and  buffer 
sizing  can  be  rearranged  for  better  performance  results. 

Hardware  configuration  sizing  can  also  be  estimated 
according  to  the  workload  characterization  over  the  total 
time  of  the  SPLICE  contract. 
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By  definition,  a  primary  event  is  one  whose  time  of 
occurrence  is  scheduled  in  advance  of  its  actual  occurrence. 
Any  event  which  is  not  primary  is.  by  definition,  secondary. 
Secondary  events,  then,  are  not  scheduled  in  advance.  They 
occur  when  primary  events  do,  but  in  "dependent"  fashion,  as 
a  direct  result  of  primary-event  occurence. 
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Simulation  time  elapses  as  events  occur  in  a  simula¬ 
tion,  one  by  one.  It  is  natural,  then,  to  use  a  "simulated 
clock"  as  part  of  a  queueing-system  model.  A  variable  has 
to  be  introduced  to  represent  the  "simulated  clock"  and  this 
variable  is  then  used  to  record  what  simulated  time  it  is. 

A  "bootstrapping"  technique  is  used  to  establish 
transaction  arrival  times.  That  is,  when  an  arrival  occurs 
a  procedure  is  set  up  for  determining  the  time  of  the  next 
arrival.  The  time  of  the  first  arrival  must  be  scheduled  as 
one  of  the  steps  taken  to  initialize  the  simulation.  Assume 
that  when  a  simulation  begins,  the  simulated  clock  itself  is 


initialized  with  a  value  of  zero.  Then,  to  schedule  the 
first  arrival,  a  sample  is  drawn  from  the  interarrival-time 
distribution  at  this  first  clock  reading.  The  sampled  value 
equals  the  future  time  at  which  the  first  arrival  will 
occur.  For  example,  if  a  value  of  15  is  drawn  from  an 
interarrival-time  distribution,  then,  the  first  arrival  will 
occur  at  15. 

GPSS  uses  an  integer  clock  and  this  is  appropriate 
for  the  One-Line,  One-Server  Queueing  system,  because 
interarrival  times  and  service  times  are  assumed  to  be 
integer  valued. 

The  unit  of  time  can  be  any  time  interval  used  as 
time  unit.  In  practice,  the  unit  of  simulated  time  must  be 
small  enough  to  realistically  reflect  the  time  spans  which 
occur  in  the  system  being  modeled.  Since  we  are  modeling  a 
computer  system,  the  time  unit  should  be  one  millisecond. 

Now  suppose  that  the  simulation  is  in  progress,  and 
the  state  of  the  system  has  just  been  updated  at  the  current 
point  in  simulated  time.  The  next  logical  step  is  to 
"advance  the  clock".  There  are  two  alternative  ways  to  find 
the  value  at  which  the  clock  should  be  advanced. 

a.  Advance  the  clock  by  exactly  one  time  unit. 
Then  scan  the  system  to  determine  whether  any  events  have 
been  scheduled  to  occur  at  this  new  clock  reading.  If  so. 
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update  the  system  by  performing  the  logic  for  these  events, 
then  advance  the  clock  again  by  one  time  unit,  and  so  on. 
When  testing  indicates  no  events  have  been  scheduled  to 
occur  at  the  clock’s  new  reading,  simply  advance  the  clock 
immediately  to  its  next  value.  The  logic  of  this  approach, 
uses  a  fixed  time- increment  clock.  This  approach  causes  a 
very  high  CPU  overhead  in  simulation  model  execution. 

b.  The  second  approach  to  clock  maintenance 
uses  a  variable  time- increment  clock.  In  this  approach, 
when  conditions  call  for  advancing  the  clock,  it  is  advanced 
to  the  time  of  the  "imminent  event".  The  imminent  event  is 
the  one  which  has  been  scheduled  to  occur  at  the  next 
earliest  point  in  simulated  time.  In  general,  then,  the 
amount  by  which  the  clock  is  advanced  differs  from  advance 
to  advance,  giving  rise  to  the  phrase  "variable  time- 
increment  clock". 

The  apparent  advantage  of  the  var iable-time  incre¬ 
ment  clock  seems  to  be  that  intermediate  points  in  time  when 
nothing  has  been  scheduled  to  occur  anyway  are  skipped  over, 
thereby  probably  saving  computer  time.  This  is  not  always 
true  though  depending  upon  the  number  of  primary  events  in 
the  system.  In  our  case  we  will  use  the  variable  time- 
increment  clock. 

Finally,  care  should  be  taken  to  distinguish  between 
simulated  time  and  real  time.  When  the  simulation  clock  is 


advanced  to  a  next  reading,  that  reading  remains  fixed  while 
the  model  is  updated.  Nevertheless,  real  time  passes  as  the 
updating  occurs.  It  may  require  hours  of  real  time  to  move 
models  of  some  systems  through  only  minutes  of  simulated 
time.  One  the  other  hand,  experiments  equivalent  to  weeks, 
months,  or  even  years  of  simulated  time  can  often  be 
conducted  in  only  seconds  of  real  time  in  the  computer. 

B.  APPROACH  TAKEN  IN  BUILDING  THE  MODEL 

It  would  be  relatively  easy  to  model  the  SPLICE  LAN 
model  by  using  twelve  model  segments,  one  for  each  class  of 
transactions.  When  a  job-transaction  entered  the  model,  its 
transaction  class  could  then  be  routed  to  the  appropriate 
model  segment.  There,  it  would  move  through  a  straight 
sequence  of  blocks-  consisting  of  an  ENTER-ADVANCE-LEAVE 
combination  for  each  functional  module  (server)  being 
visited.  Throughout  the  model,  block  operands  would  be 
specified  by  using  random  number  generators  and  exponental 
interarrival  and  service  time  distributions. 

The  disadvantages  in  taking  the  approach  outlined  above 
are  that  (1)  a  relatively  large  number  of  blocks  would  be 
required,  and  (2)  a  relatively  inflexible  model  would 
result.  Instead  of  taking  such  an  approach.  Matrix  save 
values  will  be  used  to  build  a  compact  model.  The  principal 
part  of  the  required  model  is  a  single  ENTER- ADVANCE -LEAVE 
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sequence-  This  single  sequence  can  be  used  to  simulate  use 
of  consecutive  modules  (servers)  by  all  the  transaction 
classes,  providing  that  the  following  provisions  are  made: 

1.  The  pertinent  module  number  must  be  supplied  as  the 
A  operand  at  the  ENTER  and  LEAVE  blocks. 

2.  The  pertinent  mean  service  time  must  be  provided  as 
the  A  operand  at  the  ADVANCE  block. 

3.  Each  transaction  must  move  through  the  single  ENTER- 
ADVANCE-LEAVE  block  sequence  the  proper  number  of 
times  (one  time  for  each  module  to  be  visited) . 

4.  Availability  of  physical  resources  must  be  tested 
before  entering  the  ENTER-ADVANCE-LEAVE  block 
sequence . 

Table  V-I  enumerates  the  functional  modules  in  order  to 
use  the  corresponded  numbers  in  the  matrices  instead  of  the 
actual  names.  Table  V-II  provides  the  total  number  of 
modules  to  be  visited,  the  module  visitation  sequence  and 
the  mean  service  time  for  each  module  per  transaction  class, 

The  means  for  making  these  provisions  will  now  be 
considered. 

As  for  provisions  (1)  and  (2) ,  the  pertinent  module 
numbers  can  be  stored  in  the  right  order  in  a  visitation- 
sequence  Matrix  (Table  V-III);  and  the  pertinent  mean 
service  times  can  be  correspondingly  stored  in  a  mean- 
service-time  Matrix  (Table  V-IV) .  At  the  ENTER  block,  a 
transaction  then  simply  needs  to  index  into  the  proper  cell 
of  the  visitation-sequence  Matrix  to  obtain  the  number  of 
the  module  it  must  visit  next;  similarly,  when  a  module  has 


TABLE  V-I 


MODULE  (SERVER)  ENUMERATION 

Local  Communication  (LC) 
National  Communication  (NC) 
Front-End  Processing  (FEP ) 
Terminal  Management  (TM) 
Data  Base  Management  (DB) 
Session  Services  (SS) 
Peripheral  Management  (PM) 
Recource  Allocation  (RA) 


TABLE  V-III 


VISITATION  SEQUENCE  MATRIX 
(Hypothetical  Data) 


ROWS 

(Trans-Class ) 


1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 


COLUMNS 

(Number  of  modules  yet  to  be  visited) 
12345678 


5 
8 

6 
6 
5 

4 
7 
3 

5 
3 
2 
2 


6 

6 

4 

4 

6 

1 

6 

6 

3 

4 
6 

5 


4 

4 


2 

4 


4 

4 

6 

2 

4 

6 


NOTE:  The  cells  represent  the  identification  of  the  modules 

to  be  visited  next. 


TABLE  V-IV 


ROWS 

(Trans-Class ) 


MEAN  SERVICE  TIME  MATRIX 
(pisec ) 


COLUMNS 

(Number  of  modules  yet  to  be  visited) 
12345678 


been  captured,  the  transaction  can  index  into  the  corres¬ 
ponding  cell  in  the  mean  service-time  Matrix  to  obtain  the 
pertinent  value  of  the  A  operand  at  the  ADVANCE  block.  With 
respect  to  provision  (3) ,  the  number  of  modules  a  trans¬ 
action  must  visit  can  be  stored  in  a  parameter  of  the 
transaction  when  it  first  enters  the  model.  After  each 
service  has  been  performed,  the  parameters  can  be  decre¬ 
mented  by  1 .  then  tested  to  determine  whether  there  are  yet 
more  services  to  be  performed  (that  is,  tested  to  determine 
whether  the  parameter  has  yet  been  decremented  to  a  value  of 
0) .  If  at  least  one  additional  service  is  indicated,  the 
transaction  can  be  routed  back  through  the  ENTER-ADVANCE- 
LEAVE  sequence.  Then  the  parameter  can  be  decremented  and 
tested  again,  etc.  Finally,  with  respect  to  provision  (4) . 
the  physical  resources  that  a  transaction  needs  can  be 
stored  in  parameters  of  the  transaction,  one  for  each 
resource,  when  the  transaction  first  enters  the  model.  The 
availability  of  the  resources  required  by  the  transaction 
can  be  tested  by  comparing  the  parameter  value  for  each 
particular  physical  resource  which  is  stored  in  a  table  and 
updated  for  every  entering  transaction  in  the  ENTER-ADVANCE- 
LEAVE  block  sequence  and  for  every  transaction  completion 
(That  is,  the  value  of  the  required  physical  resource  per 
transaction  is  subtracted  from  the  current  value  of  the 
corresponded  value  in  the  table  and  if  the  result  is  a 


negative  number,  then  the  transaction  does  not  enter  the 
ENTER- ADVANCE- LEAVE  block  sequence,  creating  a  queue  line  at 
that  particular  resource;  if  the  result  is  zero  or  a 
positive  number,  then  the  other  resources  are  tested  in  the 
same  way  and  if  the  results  are  zero  or  positive  numbers, 
then  the  contents  of  the  current  values  in  the  table  are 
changed  to  the  new  current  values  (reduced)  and  the 
transaction  enters  the  ENTER- ADVANCE -LEAVE  block  sequence. 
When  the  transaction  completes  its  service  and  exits  the 
model,  then,  the  released  physical  resources  are  added  to 
the  current  values  of  the  table  becoming  available  for  other 
transactions)  . 

i-  Set=UB-and-.Use.  of . Matrices 

We  now  consider  more  closely  how  the  visitation 
sequence  and  mean  service  time  matrices  can  be  set-up  and 
used.  Table  V-III  shows  the  appearance  of  the  visitation 
sequence  matrix,  assuming  that  GPSS  storages  1  through  8  are 
used  to  simulate  functional  modules  (servers)  1  through  8 
respectively.  There  are  twelve  rows  in  the  matrix,  one  for 
each  transaction  class.  There  are  eight  columns  in  the 
matrix,  corresponding  to  the  maximum  number  of  modules 
(servers)  that  any  one  transaction  class  must  visit.  The 
column  numbers  are  interpreted  as  the  number  of  modules  to 
be  visited  by  a  given  transaction  class.  Entries  in  the 


body  of  the  matrix  are  interpreted  as  the  numbers  of  the 


modules  (servers)  to  be  visited  next.  For  example,  as 
indicated  in  Table  V-III,  a  transaction  of  class  1  must 
visit  three  modules.  When  it  first  arrives  into  the  system, 
the  number  of  modules  to  be  visited  is  three.  In  column  3, 

row  1  of  Table  V-III.  the  number  of  the  module  to  be  visited 

next  (that  is.  to  be  visited  first)  is  found  to  be  "4". 
Module  "4"  is  TM  (as  indicated  in  Table  V-I) ,  and  as  Table 
V— II  shows,  the  first  service  on  transaction  class  1  is 
performed  in  module  TM.  Row  1.  column  3  of  the  visitation 
sequence  matrix  therefore  contains  the  pertinent  module 
number.  When  the  terminal  management  operation  has  been 
performed,  a  class  1  transaction  has  only  two  modules  yet  to 
be  visited.  Row  1.  column  2  of  the  visitation  sequence 
matrix  should  consequently  contain  the  number  of  the  module 
to  be  visited  next.  The  number  in  that  cell  is  a  "6". 

Module  "6"  is  session  services  and,  as  Table  V-II  shows,  the 

second  operation  on  transaction  class  1  is  indeed  performed 
in  SS.  and  so  on. 

Table  V— IV  shows  the  mean  service  time  matrix.  Row 
and  column  indices  have  the  same  significance  and  interpre¬ 
tations  as  in  Table  V-III.  Entries  in  the  body  of  the 
matrix  are  mean  service  times,  expressed  in  milliseconds 
(time  unit) .  The  entries  in  the  given  cells  in  Table  V-IV 
are  linked  directly  to  entries  in  the  corresponding  cells  in 
Table  V-III.  For  example,  when  transaction  class  1  visits 
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module  4  (row  1.  column  3,  Table  V-III)  ,  its  mean  service 
time  there  is  30  milliseconds  (row  1.  column  3,  Table  V-IV) . 
Then,  when  transaction  class  1  visits  module  6  (row  1. 
column  2.  Table  V-III).  its  mean  service  time  there  is 
15  milliseconds  (row  1.  column  2,  Table  V-IV).  and  so  on. 

It  is  a  simple  matter  for  a  transaction  to  index 
into  the  proper  cell  of  the  visitation  sequence  and  mean 
service  time  matrices.  Assume  that  when  a  transaction 
enters  the  model,  its  transaction  class  is  coded  in 
Parameter  1  as  al,  or  2,  or  ...  12.  Parameter  1  can  then 
be  used  as  a  matrix  row- index.  Assume  further  that  when  a 
transaction  arrives,  the  number  of  modules  it  must  visit 
(yet  to  be  visited)  is  copied  to  Parameter  2.  Parameter  2 
can  then  be  used  as  a  matrix  column- index.  When  the  first 
operation  (service)  has  been  performed.  Parameter  2  can  be 
decremented  by  1,  meaning  that  (1)  its  value  can  be 
interpreted  as  the  number  of  modules  yet  to  be  visited,  and 
(2)  its  value  can  continue  to  be  used  as  the  appropriate 
martix  column- index.  Suppose  that  halfword  matrix  save 
value  1  is  used  for  the  visitation  sequence.  Then 
"MHl(Pl.P2) "  indirectly  specifies  the  proper  current  module 
number  for  the  scheme  just  described.  -Suppose  further  that 
halfword  matrix  save  value  2  is  used  for  the  mean  service 
times.  Then,  because  of  the  cell-to-cell  correspondence 
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between  the  two  matrices.  "MH2(Pl,P2)n  indirectly  specifies 
the  corresponding  mean  service  time. 

Model  Segment  1,  shown  in  Figure  5-2,  should  appear 
brief  and  straightforward.  Location  names  have  been 
supplied  for  the  ASSIGN  blocks,  the  ADVANCE  block  and  the 
TEST  block.  At  any  given  time,  all  jobs  -  transactions  in 
the  system  -  are  either  at  these  ASSIGN  blocks  (waiting  for 
disk  or  memory  or  processing  unit,  in  order  to  move  into  the 
ENTER  block) ,  or  the  ADVANCE  block  (because  they  are  on  the 
future  events  chain) »  or  at  the  TEST  block  (waiting  to  move 
into  the  ENTER  block  again) .  Hence,  the  sum  of  the  current 
counts  at  these  blocks  equals  the  total  number  of  trans¬ 
actions  in  the  model.  The  variable  COUNT  has  this  sum  of 
current  counts  in  its  value.  It  is  this  variable  that  is 
evaluated  at  the  end  of  each  simulated  period  (six  months) 
to  determine  how  many  transactions  are  currently  in  the 
system. 

A  timer-transaction  enters  Model  Segment  2  at  the 
end  of  each  six  month  period  to  record  the  value  of  the 
variable  COUNT  in  the  Table  T  Jobs.  After  the  processor 
resets  the  model  to  eliminate  statistics  accumulated  during 
this  period,  the  simulation  for  the  next  period  is  started. 

-Sample  format. for  the  output  of  the  entire  eleven 
years  (1982-1993)  simulation  period  is  shown  in  Table  V-VI. 
This  figure  is  provided  only  to  show  format.  It  does  not 
show  actual  results  from  the  simulation. 
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Operant 

A 


Default  Value 


•  lV/- 


v  w-  -V* 


K‘ 

K 

d 

. 

■ 

. 

k\  V  '■ 


B 

C 

D 

E 


Significance 

Name  of  the  matrix  in 
which  an  element  is  to 
be  modified 


Error 


Row  subscript  Error 

Column  subscript  Error 


Data  to  be  used  in  the 
modification  process  Error 


The  character  H  indicates 
that  the  matrix  is  on  the 
halfword  type 


Matrix  is  of 
the  fullword 
type 


Figure  5-1.  The  MSAVEVALUE  Block  and  its  A,  B,  C,  D,  E 
Operands 
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Generate 


JOB  ENTER  THE  SYSTEM 


SET  Pi  EQUAL  TO  JOB  CLASS 


SET  P2  EQUAL  TO  NO.  OF 
OF  MODULES  TO  VISIT 


FORM  QUEUE  ON  DISK 


DEPART  FROM  QUEUE-DISK 


SET  P3  EQUAL  TO  REQUIRED 
THE  JOB  DISK  CAPACITY 


Figure  5.2. 


Block  Diagram  for  GPSS  Program 
(Hypothetical  Data) 


i  -J 


QUEUE 


J0BQ2 


t 


DEPART 


J0BQ2 

T 


4 , FN$MEM 


QUEUE 


J0BQ3 


© 


IS  DISK  AVAILABLE? 

IF  NOT  GO  BACK  TO  QUEUE  LINE. 


FORM  QUEUE  ON  MEMORY  STORAGE 


DEPART  FROM  MEMORY  QUEUE 


SET  P4  EQUAL  TO  MEMORY 
CAPACITY  REQUIRED  BY  THE  JOB 


IS  MEMORY  CAPACITY  AVAILABLE? 
IF  NOT  GO  BACK  TO  QUEUE  LINE. 


FORM  QUEUE  ON  PROCESSING  UNITS 


Figure  5.2  (continued) 


DEPART  FROM  PROCESSING  QUEUE 


SET  P5  EQUAL  TO  PROCESSING 
UNITS  REQUIRED  BY  THE  JOB 


ARE  PROCESSING  UNITS  AVAILABLE? 
IF  NOT  GO  BACK  TO  QUEUE  LINE. 


CAPTURE  NEXT  MODULE 


JOB  SERVICING  PROCESS 


RELEASE  THIS  MODULE 


Figure  5.2  (continued) 
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(EEE) 


UPDATE  NO.  OF  MODULES  YET 
TO  BE  VISITED 


JOB  DONE?  IF  NOT  GO  TO 
NEXT  MODULE. 


YES,  RECORD  TIME  SPENT  IN 
THE  SYSTEM 


LEAVE  THE  SYSTEM 


MODEL  SEGMENT  1 


Figure  5.2  (continued) 
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TIMER  ARRIVES  AT  END  OF 
EACH  SIX  MONTH  PERIOD 


RECORD  NO.  OF  JOBS  NOW  IN 
THE  SYSTEM 


DECREMENT  TERMINATION 
COUNTER 


MODEL  SEGMENT  2 


Figure  5.3. 


Model  Segment  2  Diagram 
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TABLE  V-V 


GPSS  ENTITY 

Transactions 
Model  Segment  1 


Model  Segment  2 

Functions 

MDLS 


TRCLS 


XPDIS 

Matrix  Savevalues 
1 
2 

Storages 

1,2, 3, 4, 5, 6, 7, 8 

Tables  1 , 2 ,  ...  12 


TIOBS 


TABLE  OF  DEFINITIONS 

INTERPRETATION 


A  transaction 

PI:  Parameter  1  values  of  1,2...  12 

indicate  transactions  of  class  1 
through  12  respectively. 

P2 :  Parameter  2  indicates  the  total 

number  of  modules  "yet  to  be 
visited"  by  a  transaction. 

P3:  Parameter  3  indicates  the  required 

transaction  class  disk  storage. 

P4 :  Parameter  4  indicates  the  required 

transaction  class  memory  storage. 

P5:  Parameter  5  indicates  the  required 

transaction  class  processing  units. 

A  timer-transaction 


A  function  describing  the  total  number 
of  modules  each  transaction  class  must 
visit. 

A  function  describing  the  distribution 
of  transaction-classes  within  the  stream 
of  arriving  transactions. 

Exponential  distribution  function. 

(Halfword ) 

Visitation  sequence  matrix. 

Mean  service  time  matrix. 

Storages  used  to  simulate  modules  1 
through  8,  respectively. 

Tables  in  which  the  system  residence 
times  of  transaction  class  1  through  12, 
respectively,  are  recorded. 

Table  used  to  record  the  total  number  of 
transactions  in  the  system  at  the  end 
of  each  six-month  period. 

A  variable  whose  value  equals  the  total 
number  of  transactions  in  the  system. 


Variables  COUNT 


TABLE  V-VI 


PROGRAM  OUTPUT 
(Hypothetical  Data) 


Average  Number  Average  System  Residence  Time  ( usees,  by 

of  Transactions  transaction  class) 


in  System 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

1982.0 

1100 

250 

110 

50 

300 

220 

180 

100 

40 

30 

20 

10 

400 

.5 

1180 

300 

120 

58 

350 

230 

185 

120 

50 

35 

28 

20 

450 

1983.0 

1200 

320 

i 

140 

1 

65 

i 

370 

l 

250 

i 

198 

l 

180 

l 

68 

l 

40 

i 

36 

l 

30 

i 

480 

1 

.5  1240 

1984.0  1290 

.5  1340 

1985.0  1380 

.5  1400 

1986.0  1450 

.5  1520 

1987.0  1600 

.5  1640 

1988.0  1700 

.5  1740 

1989.0  1800 

.5  1830 

1990.0  1880 

.5  1900 

1991.0  1950 

.5  2000 

1992.0  2050 

.5  2150 

1993.0  2200 
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VI.  CONCLUSIONS 


Simulation  is  a  technique  of  growing  importance  in  many 
fields,  theoretical  and  applied.  Distributed  computer 
systems  of  any  kind  are  too  complex  to  predict  their  per¬ 
formance  without  the  aid  of  a  tool,  such  as  simulation. 

The  generation  of  a  representative  job  stream  is  one  of 
the  most  important  considerations  in  developing  a  simulation 
model  for  a  computer  system.  First,  parameter  values  must 
reflect  the  characteristics  of  individual  jobs  that  are 
processed  by  the  computer  that  is  being  simulated.  Second, 
a  set  of  individual  jobs  must  be  selected  to  represent  the 
total  workload  of  the  computer.  The  third  consideration 
involves  generation  of  jobs  with  a  pattern  of  interarrival 
times  that  matches  the  actual  workload  on  the  computer 
system. 

The  specifications  of  a  Local  Area  Network  (LAN)  simula¬ 
tion  model  have  been  given  in  this  thesis  based  on  a  SPLICE- 
LAN  functional  design.  The  model  is  specified  to  allow  the 
evaluation  of  alternative  LAN  technologies  operating  under 
the  forecasting  workload  of  the  SPLICE  system. 

The  resolution  and  amount  of  detail  to  be  presented  in 
the  model  depends  on  the  questions  to  be  asked  of  the  model. 
The  more  specialized  a  model  becomes,  the  less  able  it  is  to 
answer  new  and  unexpected  questions.  For  the  SPLICE  LAN 


design  in  its  present  state  of  development,  the  simulation 
model  appears  to  be  adequate  for  obtaining  a  basic 
understanding  of  network  performance. 

It  should  be  emphasized  though  that  the  construction  of 
a  simulation  model  is  an  iterative  process.  The  LAN  model 
specified  in  this  thesis  can  be  considered  as  a  first 
generation  model  which  allows  for  future  growth  by 
proceeding  to  a  more  complex  and  sophisticated  level  in 
future  generation  models. 
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PROCESS-  ERROR  VAL-  VALIDATION 


APPENDIX  B 


PROCESS  LOAD  FORECASTS  FOR  NSC  NORFOLK  [Ref.  3] 


& 

M 

a 


M  t* 


8 


n 

2 

3 

D 

5 

6 

7 

8 

9 

10 

11 

12  1 

MESSAGE  LENGTH 

■ 

m 

fl 

50 

175 

800 

m 

175 

30 

m 

80 

m 

NO.  OF  INSTRUCTIONS 

I 

1 

100 

100 

250 

100 

300 

B 

30 

] 

%  OF  FAILURE 

B 

i 

B 

1 

5 

8 

■ 

5 

2 

10 

2 

B 

NO.  OF  RECORDS 

i 

so 

18 

n 

8 

20 

i 

8 

5 

20 

5 

0 

RECORD  LENGTH 

1500 

350 

250 

350 

250 

150 

350 

150 

0 

NO.  OF  INSTRUCTIONS 
PER  ACCESS 

5 

20 

i 

20 

30 

10 

10 

20 

30 

20 

0 

%  FAIL 

0 

i 

1 

B 

2 

.  3 

1 

2 

3 

3 

3 

0 

NO.  OF  INSTRUCTIONS 

0 

0 

0 

50 

150 

500 

B 

130 

300 

500 

500 

0 

%  FAIL 

0 

0 

0 

1 

1 

2 

■ 

2 

2 

.  2 

2 

0 

NO.  OF  INSTRUCTIONS 

5 

5 

5 

30 

fil 

m 

23 

40 

m 

H 

m 

35 

MESSAGE  LENGTH 

80 

80 

80 

500 

Ea 

fl 

m 

800 

D 

3 

n 

150 

NO.  OF  RECORDS 

0 

0 

0 

0 

5 

m 

0 

4 

100 

■ 

25 

1 

RECORD  LENGTH 

0 

0 

0 

0 

200 

I 

0 

200 

300 

■ 

150 

80 

NO.  OF  INSTRUCTIONS 

0 

0 

0 

0 

10 

B 

0 

15 

5 

■ 

15 

10 

NO.  OF  INSTRUCTIONS 

0 

0 

0 

0 

175 

250 

0 

175 

500 

250 

2500 

50 

NO.  OF  INSTRUCTIONS 

0 

0 

0 

20 

30 

30 

20 

20 

20 

30 

20 

10 

NO.. OF  MODIFIED 
RECORD 

m 

0 

0 

0 

5 

15 

1 

10 

200 

20 

5 

0 

LENGTH  OF  MODIFIED 
RECORD 

0 

0 

0 

0 

200 

250 

200 

250 

100 

350 

250 

0 

NO.  OF  ADDS 

0 

0 

0 

1 

2 

15 

0 

0 

100 

0 

2 

1 

LENGTH  OF  ADDED 
RECORD 

0 

0 

0 

100 

250 

350 

0 

0 

200 

0 

75 

80 

NO.  OF  INDICIES 

0 

0 

0 

5 

10 

10 

5 

0 

4 

0 

3 

2 

NO.  OF  INSTRUCTIONS 

5 

50 

50 

20 

30 

50 

B| 

30 

50 

50 

50 

Q 

MESSAGE  LENGTH 

1500 

500 

m 

750 

132 

80 

m 

NO.  OF  RECORDS 

1 

1 

1 

1 

1 

1 

i 

1 

400 

1 

125 

B 
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APPENDIX  C 


NSC  NORFOLK 

GOODNESS  OF  FIT  TEST  FOR  TOTAL  DATA  INDEPENDENTLY  OF 

TRANSACTION  CLASS 


Interval 

Number 

Interval 

Mean 

Observed 

Frequency 

Probability 

Expected 

Frequency 

i 

xi 

Xi 

ni 

P. 

i 

t . 
i 

1 

•  2lxl!  ■  8 

1.0 

178 

.6687 

192.59 

2 

1 . 8<x<3 . 4 

2.6 

58 

.1666 

47.98 

3 

3 . 4  <x<5 

4.2 

21 

.0570 

16.42 

4 

5fx<6 . 6 

5.8 

7 

.9243 

6.99 

5 

6 . 6<x<8 . 2 

7.4 

0 

.0118 

3.40 

6 

8 . 2  <x<9 . 8 

9 

0 

.0067 

1.93 

7 

9 . 8 <x<ll . 4 

10.6 

0 

.0038 

1.10 

8 

11.4<x<13 

12.2 

0 

.0022 

.63 

9 

13<x<14.6 

13.8 

1 

.0015 

.43 

10 

14 . 6<x<16 .2 

15.4 

5 

.0010 

.29 

11 

16 . 2<x<17 . 8 

17 

5 

.0007 

.20 

12 

17 .8<x<19.4 

18.6 

5 

.0005 

.15 

13 

19.4<x<21 

20.2 

4 

.0003 

.09 

14 

21<x<22 . 6 

21.8 

4 

.0003 

.09 

288  272.3 


To  find  the  probability  that  a  random  variable  having  the 
log-normal  distribution  assumes  a  value  between  a  and  b  (0<a<b) , 
we  apply  the  following  formula: 

-1  e-  UnX->  2/2f2  dx 


P (a<X<b)  = 


X 
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Changing  variables  by  letting  y  =  Z^X  and  hence, 
dy  =  X  "'"dX,  we  obtain: 


V 

i<X<b)  =  I 

-'fl  — 


e-(y-«)2/262dy 


and  it  can  be  seen  that  this  probability  equals  the  probability 
that  a  random  variable  having  the  normal  distribution  with 
u=a  and  =£  assumes  a  value  between  £na  and  p^b.  Thus, 


£  b-a  £  a-ct 

p(a<X<b)  =  F(-^ — )  -  F  (~~g — ) 

where  F(Z)  is  the  probability  that  a  random  variable  having  the 
standard  normal  distribution  assumes  a  value. 

The  long-normal  distribution  occurs  in  practice  whenever 
we  encounter  a  random  variable  which  is  such  that  its  logarithm 
has  a  normal  distribution. 

Testing  logarithmic  distribution  with  parameter  values 
a=0,  £=1  we  have: 


1.1053  +  2.0926  +  1.2354  +  0  +  3.4  +  1.93 
+  1.1  +  .63  +  .7556  +  76.49  +  115.19  +  ... 


=  530.6 


Taking  the  sum  up  to  9th  interval  we  have 


12.27. 


From  the  x2  tables  we  have  the  following  values: 


a.  Degree  of  freedom  13  x2  -  *05  =  22.362 

b.  Degree  of  freedom  8  x2  -  .05  =  15.507 

Since  x2>x^  05  ^YPot^esis  that  the  distribution  is 

logarithmic  cannot  be  accepted.  Other  theoritical  distributions 
have  been  tested  without  good  results.  Taking  the  intervals 
up  to  the  9th  interval,  we  find  that  x2<x2g  and  consequently 

the  hypothesis  cannot  be  rejected  for  those  particular  data. 

Some  data  smoothing  can  be  applied  in  order  for  the  data  to  fit, 
but  even  so,  the  logarithmic  distribution  does  not  fit  the  data. 
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APPENDIX  E 


NCS  NORFOLK 

GOODNESS  OF  FIT  TEST  ON  DATA  FOR  TRANSACTION  CLASS- 1 


OVER 

1982-1993 

Interval 

Observed 

Expected 

Number 

Interval 

Mean 

Frequency 

Probability 

Frequency 

i 

I . 

X  • 

n . 

P . 

t . 

i 

Ai 

l 

i 

l 

1 

3 . 5<x<3 . 9 

3.7 

5 

.182 

4.368 

2 

3 . 9<x<4 . 3 

4.1 

5 

.182 

4.368 

3 

4.3<x<4.7 

4.5 

4 

.182 

4.368 

4 

4 .  7<x_<5 . 1 

4.9 

4 

.182 

4.368 

5 

5 . l<x<5 . 5 

5.3 

4 

.182 

4.368 

6 

5 . 5<x<5 . 7 

5.6 

2 

.090 

2.160 

24  24 


Testing  for  uniform  distribution  we  have: 

=  .091  +  .091  +  .091  +  .091  +  .091  +  1.376 

=  1.831 

With  degree  of  freedom  5  and  level  of  significance  =  .05 
we  have  from  the  tables  XJg^  =  11.070. 

Since  x2<x|-  Q5  the  hypothesis  cannot  be  rejected  and  the 
data  fit  in  a  uniform  distribution. 


V  (ni~V2 

'  i-1  ^ 


86 


APPENDIX  F 
NSC  NORFOLK 

GOODNESS  OF  FIT  TEST  ON  DATA  FOR  TRANSACTION  CLASS-2 

OVER  1982-1993 


Interval  Observed  Expected 


Number 

Interval 

Mean 

Frequency  Probability 

Frequen 

i 

I . 
i 

xi 

n . 
i 

P. 

l 

t . 
i 

1 

1 . 0  <x<l . 1 5 

1.075 

5 

.167 

4.008 

2 

1.15<x<l .3 

1.225 

5 

.167 

4.008 

3 

1 . 3  <x<l . 4  5 

1.375 

5 

.167 

4.008 

4 

1 . 45<x<l . 6 

1.525 

4 

.167 

4.008 

5 

1 . 6<x<l . 75 

1.675 

3 

.166 

3.984 

6 

1.75  <x<l . 8  3 

1.825 

2 

.165 

3.96 

24 

23.976 

Testing 

for  uniform 

distribution  we 

have : 

•Wi 

ll 

N 

X 

fci 

.246  +  . 

246  +  . 

246  +  0  +  .243  + 

.970 

=  1.951 


With  degree  of  freedom  5  and  level  of  significance  =  .05 
we  have  from  the  tables  x2q5  =  11.070. 

Since  x2<x|  05  the  hypothesis  cannot  be  rejected  and  the 

data  fit  in  a  uniform  distribution. 


APPENDIX  G 


NSC  NORFOLK 

GOODNESS  OF  FIT  TEST  ON  DATA  FOR  TRANSACTION  CLASS- 3 


OVER 

1982-1993 

Interval 

Observed 

Expected 

Number  Interval 

Mean 

Frequency 

Probability 

Frequency 

i  I . 

X  . 

n . 

P. 

t . 

i 

i 

i 

i 

i 

1  . 7<x£.824 

.762 

6 

.201 

4.824 

2  .824<x<.948 

.886 

5 

.201 

4.824 

3  .948<x<1.072 

1.010 

5 

.201 

4.824 

4  1 . 072<x<l .196 

1.134 

4 

.200 

00 

• 

5  1 . 196<x<l .317 

1.258 

4 

.197 

4.728 

24 

24 

for  uniform  distribution  we  have: 

)2 

—  =  .287  +  .006  +  .006  +  .133  +  .112  =  .544 


u 

■l 


i=l 


^i^i 

fci 


With  degree  of  freedom  4  and  level  of  significance  =  .05 

we  have  from  the  tables  X2q^  =  9.488. 

Since  x2<x|  Q5  the  hypothesis  cannot  be  rejected  and  the 
data  fit  in  a  uniform  distribution. 


APPENDIX  H 


NCS  NORFOLK 

GOODNESS  OF  FIT  TEST  ON  DATA  FOR  TRANSACTION  CLASS- 4 

OVER  1982-1993 


Interval  Observed  Expected 


Number 

Interval 

Mean 

Frequency 

Probability 

Frequency 

i 

I . 

X  • 

n . 

P . 

t . 

l 

i 

l 

l 

l 

1 

. 4<x£ . 465 

.40325 

4 

.125 

3 

2 

.465<x<.530 

.46825 

4 

.125 

3 

3 

.530<x<.595 

.53325 

3 

.125 

3 

4 

.  595<x_< .  66 

.59825 

3 

.125 

3 

5 

.  6  6  <  x_<  .725 

.66325 

3 

.125 

3 

6 

. 7  2  5  <  x< . 7  9 

.72825 

2 

.125 

3 

7 

.79<x<.855 

.79325 

3 

.125 

3 

8 

.855<x<.92 

.85825 

2 

.125 

3 

24 

1.00 

24 

Testing  for  uniform  distribution  we  have: 

)z 

—  =  .333  +  .333  +  0  +  0  +  0  +  .333  +  0 
+  .333  =  1.333 

With  degree  of  freedom  7  and  level  of  significance  =  .05 
we  have  from  the  tables:  XZQ5  =  14.067. 

Since  x2<x^  Q5  the  hypothesis  cannot  be  rejected  and  the 
data  fit  in  a  uniform  distribution. 


APPENDIX  I 


NSC  NORFOLK 

GOODNESS  OF  FIT  TEST  ON  DATA  FOR  TRANSACTION  CLASS-5 


Interval 

Number 

Interval 

OVER  1982-1993 

Observed 
Mean  Frequency 

Probability 

Expected 

Frequency 

i 

I . 

X- 

n. 

P. 

t. 

i 

i 

i 

i 

1 

1 . 29<x<l . 545 

1.4175 

5 

.125 

3 

2 

1.545<x<1.8 

1.6725 

4 

.125 

3 

3 

1 .8<x<2.055 

1.9275 

3 

.125 

3 

4 

2 . 055<x<2 .310 

2.1825 

3 

.125 

3 

5 

2 . 310<x<2 .565 

2.4375 

2 

.125 

3 

6 

2 . 565<x<2 . 820 

2.6925 

3 

.125 

3 

7 

2.820<x<3.075 

2.9475 

2 

.125 

3 

8 

3.075<x<3.327 

3.201 

2 

.125 

2.98 

24 

1 

23.98 

Testing  for  uniform  distribution  we  have: 

)J 

—  =  1.333  +  .333  +  0  +  0  +  .333  +  0  +  .333 
i=l  +  .320  =  2.652 

With  degree  of  freedom  7  and  level  of  significance  =  .05 
we  have  from  the  tables:  x2q5  -  14.067. 

Since  x2<x£  hypothesis  cannot  be  rejected  and  the 

data  fit  in  a  uniform  distribution. 
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APPENDIX  J 


NSC  NORFOLK 

GOODNESS  OF  FIT  TEST  ON  DATA  FOR  TRANSACTION  CLASS-6 

OVER  1982-1993 


Interval 


Number 

Interval 

Mean 

i 

I . 

X- 

i 

l 

1 

2 . 21 <x<2 .496 

2.353 

2 

2.496<x<2.782 

2.639 

3 

2 . 782<x<3 .068 

2.925 

4 

3 . 068<x<3 . 354 

3.211 

5 

3 . 354<x<3 . 64 

3.497 

Observed  Expected 


Frequency 

Probability 

Frequency 

n . 

P. 

t . 

l 

i 

i 

6 

.2 

4.8 

5 

.2 

4.8 

5 

.2 

4.8 

4 

.2 

4.8 

4 

.2 

4.8 

24 

1.0 

24 

Testing  for  uniform  distribution  we  have: 
5 


2  _ 


-  z 


( n  .  -t .  ) 


t . 

l 


=  .299  +  .008  +  .008  +  .219  +  .219  =  .753 


i=l 


With  degree  of  freedom  4  and  level  of  significance  =  .05 
we  have  from  the  tables:  X*q5  =  9.488. 

Since  x2<X2  05  the  hypothesis  cannot  be  rejected  and  the 

data  fit  in  a  uniform  distribution. 
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APPENDIX  K 


NSC  NORFOLK 

GOODNESS  OF  FIT  TEST  ON  DATA  FOR  TRANSACTION  CLASS-7 

OVER  1982-1993 


Interval 


Observed 


Expected 


Number 

Interval 

Mean 

Frequency 

Probability 

Freque: 

i 

I . 

X  • 

n . 

s  P. 

t . 

i 

l 

i 

'  i 

l 

1 

.  56<x<^  73 

.645 

6 

•  .166 

3.984 

2 

.  73<x<. 90 

.815 

5 

.166 

3.984 

3 

. 90<x<l . 07 

.985 

4 

.166 

3.984 

4 

1.07<x<1.24 

1.155 

3 

.166 

3.984 

5 

1 . 24<x<l . 41 

1.325 

3 

.166 

3.984 

6 

1 . 41<x<l . 578 

1.495 

3 

.165 

3.96 

24 


.995 


23.88 


Testing  for  uniform  distribution  we  have: 

*  ( n . -t . ) * 

x2  =  )  — — —  =  1.02  +  .25  +  .00006  +  .24  +  .24  +  .23 

i=l 

=  1.99 


With  degree  of  freedom  5  and  level  of  significance  =  .05 
we  have  from  the  tables:  x2q5  =  H’070, 

Since  x2<X2  05  the  hypothesis  cannot  be  rejected  and  the 

data  fit  in  a  uniform  distribution. 


APPENDIX  L 


NSC  NORFOLK 

GOODNESS  OF  FIT  TEST  ON  DATA  FOR  TRANSACTION  CLASS- 8 

OVER  1982-1993 


Testing  for  uniform  distribution  we  have: 

(n  -t  )2 

— -± —  =  .99  +  .246  +  .0  +  .254  +  .233  =  1.723 

i=l 

With  degree  of  freedom  5  and  level  of  significance  =  .05 
we  have  from  the  tables:  X*q5  =  11*07. 

Since  x2<X^  c  hypothesis  cannot  be  rejected  and  the 
data  fit  in  a  uniform  distribution. 
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APPENDIX  M 


NSC  NORFOLK 

GOODNESS  OF  FIT  TEST  ON  DATA  FOR  TRANSACTION  CLASS-9 

OVER  1982-1993 


Interval 

Number 

Interval 

Mean 

Observed 

Frequency  Probability 

Expected 

Frequency 

i 

I . 
l 

Xi 

n . 
i 

P . 

l 

t . 
i 

1 

.2<x<.28 

.24 

1 

.2 

4.8 

2 

. 28<x<. 36 

.32 

8 

.2 

4.8 

3 

.36<x<.44 

.4 

6 

.2 

4.8 

4 

.44<x<.52 

.48 

5 

.2 

4.8 

5 

.52<x<.6 

.56 

4 

.2 

4.8 

24 

1.0 

24 

Testing 

for  uniform 

distribution  we 

have : 

6 

v.  -  v 

.  (n.-t.)* 

=  3.008 

+  2.133 

+  .299  +  .008  + 

.134  =  5.582 

x  L 

i=l 

With  degree  of  freedom  4  and  level  of  significance  =  .05 


we  have  from  the  tables:  X2 =  9.488. 

Since  x2<X2f  05the  hYPothesis  cannot  be  rejected  and  the 
data  fit  in  a  uniform  distribution. 


APPENDIX  N 


NSC  NORFOLK 

GOODNESS  OF  FIT  TEST  ON  DATA  FOR  TRANSACTION  CLASS-10 

OVER  1982-1993 


Interval  Observed  Expected 


Number 

Interval 

Mean 

Frequency  Probability  Frequency 

i 

I . 

X. 

n . 

P. 

t . 

i 

l 

l 

l 

l 

1 

1 . 62<x<l . 75 

1.685 

4 

.125 

3 

2 

1 . 75<x<l . 88 

1.815 

3 

.125 

3 

3 

1 . 8  8  <  x< 2 . 0 1 

1.945 

3 

.125 

3 

4 

2.01<x<2.14 

2.075 

3 

.125 

3 

5 

2 . 14<x<2 . 27 

2.205 

3 

.125 

3 

6 

2.27<x<2.4 

2.335 

3 

.125 

3 

7 

2 . 4 < x <2 . 5 3 

2.465 

2 

.125 

3 

8 

2 . 5  3  <  x <2 . 6  6 

2.595 

3 

.125 

3 

24 

1.0 

24 

Testing 

for  uniform  distribution  we 

have : 

8 

r— 

,  (n.-t.)2 

x=  I 

1  1 

,  t. 

.333 

+  0  +  0 

+  0  + 

0  +  0  +  .333 

+  0 

i= 

1 

= 

.666 

With 

degree  of  freedom  7 

and  level  of 

significance 

=  .05 

we  have 

from  the  tables 

X2 

05  =  14 

.067. 

Since  x2<Xt  nc  the  hypothesis  cannot  be  rejected  and  the 


data  fit  in  a  uniform  distribution. 
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APPENDIX  0 


NSC  NORFOLK 

GOODNESS  OF  FIT  TEST  ON  DATA  FOR  TRANSACTION  CLASS- 11 

OVER  1982-1993 


Interval 

Number 


.Interval 


Mean 


Observed 

Frequency 


Probability 


24 


1.0 


Expected 

Frequency 


i 

*i 

xi 

n . 

l 

Pi 

t . 
l 

1 

.36<x<.433 

.3965 

7 

.2 

00 

• 

2 

. 433<x^. 506 

.4695 

5 

.2 

• 

00 

3 

. 506<x£. 579 

.5425 

4 

.2 

00 

• 

4 

.579<x<.652 

.6155 

4 

.2 

• 

00 

5 

. 652<x< .725 

.6885 

4 

.2 

4.8 

24 


Testing  for  uniform  distribution  we  have: 


2  _ 
X  - 


i 

i=l 


(nrV 

fci 


=  1.009  +  .008  +  .133  +  .133  +  .133 


=  1.416 

With  degree  of  freedom  4  and  level  of  significance  =  .05 

we  have  from  the  tables: 

2^2 


X'!o5  =  9  *488  * 


Since  x2<X^  05  the  hypothesis  cannot  be  rejected  and  the 

data  fit  in  a  uniform  distribution. 
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APPENDIX  P 


NSC  NORFOLK 

GOODNESS  OF  FIT  TEST  ON  DATA  FOR  TRANSACTION  CLASS-12 

OVER  1982-1993 


Interval 

Number 

Interval 

Mean 

Observed 

Frequency 

Probability 

i 

I. 

i 

Xi 

n . 

i 

Pi 

1 

14.4<x<16.04 

15.22 

6 

.2 

2 

16.04<x<17.68 

16.86 

5 

.2 

3 

17.68<x<19.32 

18.50 

5 

.2 

4 

19.32<x<20.96 

20.14 

4 

.2 

5 

20.96<x<22.6 

21.78 

4 

.2 

24 

1.0 

Expected 

Frequency 

t. 

1 

4.8 

4.8 

4.8 

4.8 

4.8 

24 


Testing  for  uniform  distribution  we  have: 


2  _ 


“  I 


(n.-t,  ) 


i  i 


fci 


=  .299  +  .008  +  .008  +  .133  +  .133  =  .581 


i=l 


With  degree  of  freedom  4  and  level  of  significance  =  .05 
we  have  from  the  tables:  X*q5  =  9.488. 

Since  x2<x^  hypothesis  cannot  be  rejected  and  the 

data  fit  in  a  uniform  distribution. 
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